Ideas and projects for DomTerm

Basic terminal emulator functionality

Document any discrepances from xterm and ANSI

While implementing all of the features of xterm is probably not feasible, we should at least have a list of anything we don’t implement, or implement differently from xterm.

See also the ECMA-48 standard.

Error recovery and state transitions should follow this.

Use vttest for testing

The xterm distribution includes vttest. Most of the tests work now, but there are more worth fixing.

Support Sixel graphics

Sixel is an old raster image format supported by DEC terminals and some programs, including xterm. It is interesting because some programs (such as gnuplot) can use Sixel to interleave graphics and text, without requiring separate windows.

This JavaScript utility may be useful in converting raster data (post-sixel-decoding) to PNG, which could the be displayed with a data: URI. Alternatively, a <canvas> element could be used.

Improve copy and paste

Fix paste in line-editing mode.

Think about how to do multi-line paste.

Improve standalone terminal emulator

Handle saving and truncating scrolled-out output.

While qtdomterm supports tabs, moving a tab from from one window to another window does not work.

Implement “drop-down” mode.

Support other embeddable browsers

Some toolkits to explore for integrated browser/application:

Using alternate window managers

DomTerm includes a “window manager” (implemented using GoldenLayout) that supports panes and tabs. If DomTerm is integrated in an application with its own window manager, such as Atom or Visual Studio Code, it would make sense to instead integrate with the latter manager.

Similarly, when running under a tiling window manager using the latter to manage panes and tabs is likely preferable.

Tools and examples for Atom or Electron

Atom packages are in ~/.atom/packages. Seemingly helpful tutorial: “How to Write Atom Packages Using Vanilla JavaScript”.

Web browsers for Atom include atom-web-view (aka web-view), or atom-browser-webview. Neither of them work well, probably because of Atom API changes.

Terminal emulators for Electron: Extraterm (interesting, uses CodeMirror). Black Screen (extra shell features).

Terminal emulators for Atom: Term 3. terminal-plus. atom-terminal-panel. Termrk.

Tabs for Electron (compatible with dragula).

Various Electron Awesome links Community links.


We should use a “keymap” structure to manage keybindings, and you should be able add/modify keymaps from the settings.ini. A small candidate library is browserkeymap. It also also worth looking at mousetrap, though that doesn’t have a proper “keymap” concept.

Readline style hooks and improvements

The idea is the line-editing mode would provide the functionality of readline or similar programs.

Improved history support in line-editing mode

While DomTerm has basic history support (previous/next line), we should implement searching (ctrl-R in readline), as well as saving the history (in local storage).

Readline hooks to recognize when it’s running under DomTerm

The idea is readline would delegate basic line editing (and re-display) to DomTerm, while DomTerm would call back to readline for command completion, history, etc.

This has a couple of advantages over plain readline: One is to have mousing actually work (i.e. no more readline not being able to move the cursor on mouse-clicks). Another advantage is local editing, which is a benefit over slow links (such as satellites) or when you don’t want to interrupt the server needlessly.

Readline should at least behave as if the screen width were infinite, delegating line-wrapping to DomTerm.

Customizable key sequences, as in readline

Event forwarding to inferior

A process may "print"/paint graphics with event handlers. For example a button. On clicking the button, the click should be bundled as an event objects sent back to the inferior.

Saved notebooks

A "notebook" is a saved (and potentially executable) representation of a session.

IPython/Jupyter has a JSON encoding for "notebooks". This is flexible and extensible, but requires special tools.

The DomTerm notebook format should just be a simple html page. Essentially a serialization of the DOM. The page may include some generated header information and metadata. It may include references to JavaScript that would allow former execution, as well as viewing actions (like hide/unhide, wrap-to-fit, etc). This references should be simple and relative, so the actual JavaScript loaded can depend on context.

The format must be XML-compatible (XHTML) so it can be parsed by XML tools such as XSLT.

Specific format TBD.

The html page must be viewable and look reasonable in a browser even if JavaScript library or style files are missing or JavaScript is disabled.

A notebook may be include additional resources in other files, such as images. If notebook consists of multiple files, they should be bundled in a zip archive (like LibreOffice does).

Tools to convert to and from Jupyter format would be nice, so we should avoid gratuitous conceptual incompatibility.

Detachable and remote sessions

Detachable sessions means that a front-end can disconnect from a session, while the session (child process) persists. The same or a different front-end can later re-attach to the session

The GNU Screen and tmux programs support detachable sessions (along with many other features). These know the display state, so they can re-create it on a re-attach. The problem is that DomTerm has more complex state and features, which you won’t be able to use with screen or tmux.

A simpler solution that only deals with session management is abduco, or dtach. These just “pass through” escape sequences, without trying to simulate the display. The downside is this depends on client re-draw (using sigwinch or ctrl-L), which is fine for a program like emacs, but doesn’t redraw previous commands, and doesn’t work with a console-based REPL.

Handling explicit detach can be done by having the front-end serialize the important aspects of state, and send it back to the back-end. On a re-attach, the back-end can send the saved front-end state back to the front-end.

However, this doesn’t handle unexpected detaches, as when the connection dies. To support this, the back-end has to know the critical parts of the front-end state. This means the back-end has to track the front-end state by simulating the actions of the various escape sections. One way to do that is to use a “headless” web browser such as (the presumably rekativey heavy-duty) PhantomJS. Chromium has a --headless option. Using QtWebEngine in headless mode makes sense if we also use qtdomterm.

See also Mosh (also LWN article), and EternalTerminal.