ldomterm - a fork of ttyd using DomTerm rather than xterm.js

[PerBothner]

FYI: I have created a "pseudo-fork" of ttyd which uses DomTerm for the terminal emulator logic (rather than xterm.js). The server application, ldomterm, is basically ttyd, but with lots of changes to serve up DomTerm rather than xterm.js.

You can specify a --browser[=command] which uses command to automatically start a client session in a web browser. This option (which is the default if --port is not specified) implies --port 0 --once.

If you run ldomterm with no arguments it is equivalent to:

ldomterm --port 0 --once --browser="xdg-open %U" /bin/bash

The sources are on GitHub, with the ldomterm sources in the lws-term directory. Build it with ./configure --with-libwebsockets && make

DomTerm has many advantages: you can "print" images and embed general HTML; better xterm emulation (fewer vttest failures); optional input editing (a poor man's readline); export to clean HTML; and more.

Feedback welcome - if there are any xterm.js features missing (or I broke a ttyd feature) please let me know. From the website of xterm.js I gather it wins in the areas of CJK and IME.

(This isn't really an "issue", but I didn't know where else to announce this. I couldn't find an email address.)

[tsl0922]

Great 👍 , thanks for sharing this.

ttyd switched from hterm to xterm.js mainly for its CJK and IME support and other benefits like this: vercel/hyper#1275.

[PerBothner]

I'd love to add CJK and IME support to DomTerm, but I know very little about either. I can try to figure out what xterm.js is doing from the source code, but I don't know how to test things.

I tried cat-ing UTF-8.txt from https://github.com/poderosaproject/cjksample . Things did not line up correctly on any terminal emulator I tried - including xterm.js. Should I not expect this to work? Is there some font setup I can try?

Another obvious issue is accounting for double-width characters. However, that may be easy to fix, by using the wcwidth function from xterm.js and using it for DomTerm's charColumns. (Some caching of the result may be needed for performance, which makes it a bit more complicated.)

[tsl0922]

Yes, font setup is needed, check the font-family setting of ttyd, and the used font should be installed on your system or you can use web font as well.

Input and display are NOT the same thing, for example:

• hterm can display UTF-8.txt correctly but you can not input CJK characters due to the lack of IME support (you can test this with gotty).
• xterm.js supports IME, even through it's unicode support is not perfect yet, but it's more active and open than hterm, so I prefer using xterm.js (you can test this with ttyd).

As far as I know, there isn't a web terminal emulator that does both of them perfectly.

[PerBothner]

Yes, font setup is needed, check the font-family setting of ttyd,

I changed DomTerm to match.

Input and display are NOT the same thing

I know that much :-)

hterm can display UTF-8.txt correctly

I checked in changes to DomTerm, so it can now display UTF-8.txt correctly.

For "most correct" UTF-8.txt display you want East Asian Ambiguous to be treated as wide.
DomTerm uses the ambiguousCharsAreWide function, which takes a context (a containing element); you can override ambiguousCharsAreWide as appropriate. E.g. we could add escape sequences; language attributes etc etc as is most useful.

xterm.js supports IME,

I checked in experimental support for composition events, but I have no way to test it. Help with that would be very welcome.

DomTerm has two modes: In line-editing mode we basically use the contenteditable support to edit and construct a line, then on Enter it gets sent to the child. My understand of IME is that we basically want to get out the way while composition is active, and let the browser's inputhandler deal with events.

In DomTerm's character mode, a character is sent to the child process as it is typed. On composition start we basically want to act like we're in temporary line mode: Get out of the way. Then on compositionend we send the composed text to the child process.

Does that seem correct?

As far as I know, there isn't a web terminal emulator that does both of them perfectly.

I don't know about "perfectly", but my hope is DomTerm will be able to do both CJK and IME well, assuming I can get some help/testing, especially with IME.

[tsl0922]

Tested with ldomterm on OSX (PerBothner/DomTerm#28), UTF-8 display seems OK now, IME is still broken.

[PerBothner]

Thanks. Unfortunately, I don't know how to test IME. Can you recommend a simple how-to for setting up an IME on GNU/Linux? (I primarily use Fedora.) Preferably an input method oriented towards European languages and/or symbols, since I can't read non-Latin scripts.

Last time I looked the instructions I found were oriented to people who were familiar with using an IME.

[PerBothner]

I experimented a bit with the Google Input Tools Chrome extension, mostly French. (A bit confusing and poorly documented, of course.) I got things sort-of working with "line mode". (Better than xterm.js.) (A new control-shift-I keyboard binding cycles between the input modes: line, character, and automatic.) It couldn't get it to work for "character mode". A plausible way to handle IME in character mode is to temporarily enter line mode when IME is started. However, I didn't find a way to test that.

[tsl0922]

You can try ibus on fedora, these links may help:

• https://fedoraproject.org/wiki/I18N/InputMethods#Development
• https://github.com/ibus/ibus/wiki/CentOS

[PerBothner]

Thanks. I found an input method I could try out that did something interesting (rather than just re-mapping the keyboard): Norwegian with Typing Booster. I tried that with 4 combinations (both line mode and character mode, on both Firefox and Google Chrome). They all seem to work reasonably ok now.

[tsl0922]

@PerBothner May I close this now?

[PerBothner]

Yes. This wasn't an "issue" per se but since I couldn't find any email address soI thought it was worth announcing.

If there is some domterm enhancement that would induce you to switch to it, don't hesitate to request it. In particular I'm curious if the IME support is now usable.