Implement double-height/width sequences (DECSWL/DECDWL/DECDHL)

[ztmr]

xterm supports these but xterm.js does not.

#!/bin/sh
msg="Hello world!"
clear
printf "\e[1;1H"     # move to line 1, col 1
printf "\e#3${msg}"  # top-half of the message
printf "\e[2;1H"     # move to line 2, col 1
printf "\e#4${msg}"  # bottom-half of the message
printf "\e[3;1H"     # move to line 3, col 1
printf "\e#6${msg}"  # double-width message
printf "\e[4;1H"     # move to line 3, col 1
printf "${msg}\n"    # just a normal text

[Tyriar]

I'm guessing support for this is rather limited in other terminals. Here's xterm next to gnome-terminal on Ubuntu:

[egmontkob]

You might find the VTE counterpart of this issue useful. (TL;DR my conclusion was: "I personally find this feature utterly broken and useless, absolutely not worth complicating our codebase with.")

[Tyriar]

@egmontkob I want thinking this is a weird edge case that would be a pain to support and throws a bunch of things out of whack. Ultimately it looks like there is a lot of push back in VTE and I don't think it will ever be supported there so I don't think we should support. I'm open to reconsidering if support is improved though 😃

[ztmr]

So are we discussing xterm.js or vte.js? Why do you care about VTE that much? In the same way, I could argument that PuTTY/pterm does support this feature too. Your project has "full xterm terminal in your browser" in its title so I would expect it to be as much compatible with xterm as possible.

(u)xterm is the only FOSS terminal emulator close enough to the real hardware VT-series terminals so that people like me have never switched to anything else because we do need and we do use these features, althought some are missing even there. If there was no need, I wouldn't bother asking this and wasting other people's time reading this. That is also why I was so excited to see there is a project trying to implement full xterm for web.

If you insist on not having this in the core, just give me #1176 and I'll write a couple of plugins for these extra features. I prefer much more to help you designing/implementing these interfaces than maintaining a fork just to support something I need but you don't want it here.

[Tyriar]

Why do you care about VTE that much?

VTE is the base of many terminals and a good test of whether we should implement something. It's not just a question of whether xterm supports it, it's more about if most terminals support it or want to support it. There isn't much point in implementing something that would be a pain to maintain when so few people use it due to support.

Your project has "full xterm terminal in your browser" in its title

We should change that, xterm has a ridiculous amount of stuff and no one comes close to supporting everything AFAIK. The focus of xterm.js is more to enable the implementation of modern terminals, not so much support APIs that are rarely used. There is also the fact that xterm.js runs in browsers which enforces additional constraints on size and speed. In fact we had a discussion on just this recently and the tagline we're likely going to move to is "A terminal for the web"

If you insist on not having this in the core, just give me #1176 and I'll write a couple of plugins for these extra features

I have hundreds of competing priorities. All good things come in time. It would be great to get some feedback/help on #1176 from someone who wants to use the API though.

[egmontkob]

@Tyriar Thanks a lot for clarification about your project's goals. I indeed missed the title "full xterm terminal..." that @ztmr pointed out, and felt bad for giving a contradicting suggestion. (And of course, always free to ignore my suggestions and VTE's decision, I'm posting them sometimes in the hope that they might be helpful to you, but in the end it's your project and your call.)

[ztmr]

Thank you both for clarification, I truly appreciate it and didn't really want anybody to feel bad for anything! I'm a bit busy too but have some idea on what the interface would be and this is kinda edge case. I think I'll try to implement all the things I need in a separate fork, and then slowly try to generalize to see what all functions would be needed in such an interface of #1176.

[Tyriar]

@egmontkob the brief time you've been commenting here has been very useful 😄 generally I check feature support in Terminal.app/iTerm2/gnome-terminal to gauge whether a feature is worth pursuing.

@ztmr no worries, a separate fork might be best for the time being to unblock you. While you're at it if you have insights into good APIs you could use to accomplish your goals let us know 🙂