DomTerm VS jexer

Completion for program P should be written and maintained by the "owner" of program P - and installed with program P. This is of course difficult when there are many different "shells" that each have their own "language" for specifying completions. A multi-shell completion library can help with this problem.

To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special "hidden" switch to request completion.

Specifically the DomTerm terminal emulator (https://domterm.org) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic "#complete-for-bash" option followed by the existing line and position.

    complete -o nospace -C 'domterm "#complete-for-bash" "$COMP_LINE" "$COMP_POINT"' domterm

Sixel has the one advantage of being mplemented in xterm and a modest number of other terminals. Otherwise, it's a pretty bad format: Inefficient. Unclear and inconsistently implemented specification. All images have to be a multiple fof 6 pixel rows, which may not align with either image height or character height.

Some terminal implement some other protocols, but attempts to specify a standard have failed. There are some tricky issues, such as: When does an image or part of an image get erased? Can you write text on top of an image and if so how are they aligned? What happens if you write an image on top of existing text? On top of an existing image? How does scrolling affect things? What happens to the image on window resize or zoom? Can you reliably update part of an image?

DomTerm (https://domterm.org) supports images in two ways:

If interested in enhanced terminals, please take a look at DomTerm (https://domterm.org). It too optionally uses Tauri/Wry, though it can also also Electron, Qt, or a plain web-browser. You can embed images and rich text among other feayrures. DomTerm also has builtin tmux-like panes+tabs (mouse-draggable), detachable sessions, and a powerful "view" (selection) mode.

bash-preexec.sh and shell-integration.bash are copied from another terminal called DomTerm (that also offers click to position cursor) into ~/.local/share/DomTerm. Those files can be found here.

For people using or considering Mosh or Eternal Terminal: I'd love if you could try DomTerm (https://domterm.org). Specifically DomTerm's support for stable remote connections - see https://domterm.org/Remoting-over-ssh.html .

DomTerm (https://domterm.org) isn't quite what you asked for: It only indirectly has a JavaScript console: Since its frontend is a browser engine, you can open up a JavaScript debugger.

DomTerm (https://domterm.org) attempts to provide similar possibilities as TermKit. However, it starts with the position that it should also (and perhaps first) be a fully-functional modern mostly-xterm-compatible terminal emulator. On top of that we add rich html text, images, logical structure, "shell integrayion", and more.

DomTerm - JavaScript, Electron, Qt - Web browser, Linux (+ others?)

DomTerm (https://domterm.org) uses the Golden Layout library (https://github.com/golden-layout/golden-layout). As far as I can tell, this does everything mentioned in the article. It also supports tabs, and you can also reposition terminal windows by dragging, neither of which I saw mentioned in the article. (I'm currently working on being able to drag between top-level windows. It sort-of-works, but only at the proof-of-concept level.)

Please try DomTerm (https://domterm.org). The 2.9.4 AppImage (https://github.com/PerBothner/DomTerm/releases/tag/2.9.4) should have the needed support for grapheme clusters and hopefully work on reasonably up-to-date Linux systems. Of course there are more recent fixes and improvements if you don't mind building from source.

Very interesting! I was thinking literally yesterday about a TUI/GUI Qubes type concept, maybe also applicable for industrial type data diodes.

I did something like that once. Is your project online somewhere? I'm always curious what else is going on. :)

When I transliterated from D to Java around 2015, Java wasn't quite the "uninteresting" language it is perceived to be today. But all along I had hoped others might pick up some tricks, and put some notes on porting it here. Yet Java's been a pretty solid workhorse for me, and having the Swing GUI to test on was a godsend actually once I got into images.

If you code in Java, and like TUI (console type applications), then you might enjoy Jexer: https://gitlab.com/klamonte/jexer

I started Jexer in 2013, and off-and-on it's gotten better. I think my favorite part has been crossing paths with other terminal emulator ecosystem folks over the last few years. This release brings a few prettified effects inspired by other projects that you are all hopefully quite familiar with (notcurses, chafa, and vtm):

* Translucent windows, including images under/over each other and text.

* Animated/pulsing text

* Animated gifs

* A new XtermVideoPlayer example that uses ffmpeg/JavaCV to play movies inside a text-draggable window. (No audio though.)

* New button styles: round, diamond, left/right arrows. The button ends and shadows are drawn with images so specific font support is not required.

* A _much_ faster and _much_ higher quality sixel encoder.

* Different window border styles: single, double, none, and rounded corners.

* A femme theme option.

Some screenshots are posted here: https://twitter.com/AutumnMeowMeow/status/148922891703050240...

It's on maven and Sourceforge.

If you code in Java, and like TUI (console type applications), and enjoy transfemme in-jokes, then you might also enjoy jexer.

A path that started in the BBS era and is currently bringing DOOM to Xterm. And ironically, there is much better support for this now than there ever was for RIPscript.

Story time: when I first posted Jexer to Reddit, people were all "twin does that". No, it does not. twin does not pass vttest. twin has almost no widgets. twin does not support images at all, it does not multiplex images, it does not multihead images, and it does not play videos (a bit too slowly but still) in a text draggable/resizable window that could be part of a larger system. mpv/mplayer doesn't do those things either. In fact, the only two projects I know of that can do these kinds of tricks are Jexer and notcurses. (And notcurses is hella faster and great, and I would have used it in 2013 when I started Jexer, but it didn't exist then.)

One way to do translucent windows. - Inspired by notcurses

foot is great, dnkl is great. It's so far the fastest sixel-supporting terminal I've got to test XtermDOOM on. (I run iTerm2-based images against wezterm.)

It parses them, but then reduces to the 8/16 ANSI colors. Which makes translucent TUI windows not work. :(