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 🙂

[paulie-g]

generally I check feature support in Terminal.app/iTerm2/gnome-terminal to gauge whether a feature is worth pursuing

As an FYI, this is supported in Konsole (and derivatives) and several other emulators. It is rarely used because the support is spotty. DECDHL is the ideal way to implement headings in text browsers, man page viewers, markdown renderers and a number of other useful things. However, in a world where notcurses exists, applications with sophisticated TUIs no longer have to care about a terminal not supporting a feature, so the feature will get used as soon as notcurses supports it, and notcurses will (attempt to) gracefully degrade in absence of support, albeit obviously in a visibly non-ideal way, so terminal emulators missing those features will very much be shown to lack them. I understand that a) this may be difficult to implement in your rendering model, b) notcurses was not available at time this issue was filed, c) I have no standing to actually request this since xterm.js on third-party sites with default config has and continues to be unusable for me because of font resolution issues stemming from the 'courier new' default.

[jerch]

@paulie-g Ive never seen this in real world terminal applications in over 40ys (starting on a vt240 back then). We should not strive to adopt every ancient feature that hardly/never got used. There are much more convenient modern ideas, that need attention. As with any volunteer project, implementing this is just a waste of lifetime of whoever puts energy into it. Ofc be my guest and get a PR up for it...

[Tyriar]

Ive never seen this in real world terminal applications in over 40ys (starting on a vt240 back then). We should not strive to adopt every ancient feature that hardly/never got used.

I've also never seen it outside of conformance tests.

Ofc be my guest and get a PR up for it...

👍 Though the implementation would need to be sufficiently lightweight enough so as to not add too much maintenance burden.

I have no standing to actually request this since xterm.js on third-party sites with default config has and continues to be unusable for me because of font resolution issues stemming from the 'courier new' default.

Is it just because you find courier new ugly? It's the default font because I think it just always has been. If there's real problems we could switch this to monospace which should pick up the default font for the system:

https://github.com/anouartouati/xterm.js/blob/c71ef1b91a736db5fad024600f0303809215052d/src/common/services/OptionsService.ts#L24

[paulie-g]

s it just because you find courier new ugly? It's the default font because I think it just always has been. If there's real problems we could switch this to monospace which should pick up the default font for the system

No, absolutely nothing to do with aesthetics - I tend to use a modernised, TrueType recreation of a VGA-era PC BIOS font for coding most of the time, so retro looks are just fine by me. courier new quite literally breaks font selection in chromium-engined browsers (and FF as well iirc) on my system (Arch with a large number of fonts installed) and I'm not alone (there are bugs filed in this repo and many downstream projects).

I filed bugs in, iirc, one or two downstream user projects, demonstrating that it's triggering a font selection bug in the browser (and not freetype) and asking them to just use monospace, but their response was one or combination of "it's an xterm.js default, we're not changing it, go away", "if this were a real problem, xterm.js wouldn't have it as a default, go away", "you're running Linux, there's your problem, eww, go away", so either your authority is so great they can not contemplate altering the holy source code or they couldn't bother vendoring. Although I do think that this really ought to be fixed upstream, especially since downstream users are - as has been shown in practice - unable or unwilling to switch from your defaults, despite it presumably being easy to do so (Incidentally, I stopped debugging when it became clear the next stop was building chromium from source with debug symbols and stepping through their font selection code, for obvious reasons)

I would also argue that overriding the clients' choice of monospace font isn't nice, but that's secondary (and presumably you had some reason to do it, at least historically).

[jerch]

@paulie-g I also have issues with Courier New getting messed up by a tex font, see #5156.

The problem with system fonts is - we cannot do anything about it. Imho the browser will always pick the one installed on the system first, thus you cannot even override the font name with a web font. If that system font is not 100% monospace compliant, it will mess up the terminal output.

The solution is still simple - use a different font thats known to work. Thats the reason, why the terminal options have the fontFamily setting, a proper integration would expose that to the user to configure it in a user system compliant way. If the integrations dont expose that setting - what can we do? Nothing.

[paulie-g]

@paulie-g I also have issues with Courier New getting messed up by a tex font, see #5156.

My issue is distinct. From memory, browser (but not font-config) fails to find courier new (even when it's ~available), does not understand that fallback must be monospace, selects non-monospace fallback. My understanding of the root cause is that browsers are not telepathic and can not infer that a monospace font is required if you ask for courier new - they don't know it's monospace (since they can't find it), and even if they knew, don't know that this particular property is an invariant they need to maintain when choosing a fallback.

The problem with system fonts is - we cannot do anything about it. Imho the browser will always pick the one installed on the system first, thus you cannot even override the font name with a web font. If that system font is not 100% monospace compliant, it will mess up the terminal output.

Font selection in browsers is very opaque. It certainly doesn't follow font-config/freetype convention on Linux. This is why, as I've stated, it makes no sense to give browsers a chance to mess things up: they all have font preference settings, including a monospace font, which the user can change or leave at bundled default, and requesting monospace will result in that font being selected.

The solution is still simple - use a different font thats known to work. Thats the reason, why the terminal options have the fontFamily setting, a proper integration would expose that to the user to configure it in a user system compliant way. If the integrations dont expose that setting - what can we do? Nothing.

Set the font to monospace. Not some-font;some-other-font;monospace, but monospace only. That's it. The browser will use its bundled default monospace font, or the enduser can set their own choice in browser preferences. If an xtermjs library user is attached to a particular font, they can override the new monospace default. Am I missing something obvious here?

[jerch]

Set the font to monospace. Not some-font;some-other-font;monospace, but monospace only. That's it. The browser will use its bundled default monospace font, or the enduser can set their own choice in browser preferences. If an xtermjs library user is attached to a particular font, they can override the new monospace default. Am I missing something obvious here?

Does the repo demo work for you, if you set fontFamily to just 'monospace'? I am not sure, if the browsers will reliably use the system monospace font, e.g. from a sandboxed env the setting might not even be available.

I kinda agree though, that as a library-thingy xterm.js should not default to anything other than monospace. Integrators still can overwrite fontFamily to their needs and should expose the setting to users as well.

@paulie-g Can you create a new issue for that (as its kinda offtopic here) and point out there the hassles you've seen from the current fontFamily setting? Its the first time someone brought that to our attention, I wasnt aware that there are so many font-config issues behind it (beside my own finding with courier from tex fonts).

[Tyriar]

I can't recall any particular complaints about the courier fonts. I'm just going to change this to monospace:

xterm.js/src/common/services/OptionsService.ts

Line 24 in 33a5457

fontFamily: 'courier-new, courier, monospace',

I'll reopen #5156 and link to commit to that.