Ideas and projects for DomTerm

Terminal emulator functionality

Document any discrepancies 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.

Embedded HTML

If the src attribute of <img> is a relative URL (or optionally a file: URL), then the domterm html command should read the file and embed it as a data: URL. (As long as no --base option is specified.)

Highlighting

We may want to support syntax coloring (including in REPL input lines) and other highlighting. If the DomTerm element is not the only element in the <document>’s <body> then the selection may be lost to another “widget” unless we simulate the selection as a highlighted range. The mark.js package may be useful.

Improve copy and paste

Think about how to do multi-line paste.

Copying to HTML should convert <div class='domterm-pre'> to <pre> so pasting without stylesheets works better.

Scroll limit

Handle saving and truncating scrolled-out output. Most terminal emulators have “max number of lines in scroll buffer” setting. What makes this a little tricky is because there may multiple windows attached to the same session. So this would require changes to the protocol for saving/restoring and syncorinizing sessions.

Support other embeddable browsers

Some toolkits to explore for integrated browser/application:

In qtdomterm consider using QDockWidget so panes can be moved between windows.

Implement “drop-down” mode.

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.

Theia and Jupyter use PhosphorJS.

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

Compare other terminal emulators

TermySequence has lots of features. Source code.

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.

Extend use of keymaps

Keybindings for line-edit mode are controlled by a keymap data structure (based on browserkeymap, and the defaut bindings can be changed by the serrttngs file. This needs to be generalized to other modes.

Readline style hooks and improvements

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

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.

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.

Shift selection

Zsh editor (zle) supports Emacs-like mark and region. Emacs has a “shift-selection” state, which we would like to emulate.

On mouse selection, or a shift-motion command (such as Shift-Right), should set the region in shift-selection mode: We send Ctrl-Space to the client (setting the mark) at the “anchor” and move the cursor as needed. We also (locally to DomTerm) set the “shift-selection” mode. If when in shift-selection mode any (special) key is pressed without the shift modfier, then shift-selection mode is turned off, the selection is collapsed, and Escape - Ctrl-Space is sent to decativate the region.

Can do this lazily, so we only get the selection highlighting: On mouse selection or shift-motion command

JavaScript extension

It may be useful to load new JavaScript libraries into DomTerm. We can do this when loading a DomTerm web-page, by having the server add <script> elements to the generated web page. More flexible is do it dynamically:

domterm load-javascript "foo.js"

This works by essentialy doing createElement("script").

For this to be useful we need to better define the DomTerm JavaScipt API with extension hooks.

Plotting

A useful extension library would be a plotting library. The Plotly looks powerful (and big), and controlled by a JSON-able data structure.

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 sessions

Detachable sessions (similatr to GNU Screen and tmux) 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.

DomTerm implements detachable sessions using a combination of check-pointing the display state, plus having the backend recording output commands since last check-point.

This can can handle unexpected detaches, as when a connection dies. However, it’s a bit heavy-handed: check-pointing should only save parts of the state that have changed. (This gets a bit tricky when there may be multiple windows displaying the same session, combined with not-yet-implemented auto-trunctating of old output.)

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

Remote sessions

A DomTerm front-end can used used to display sessions running on remote backends. The challenge is having the remote sessions persist if connection is lost. Managing state for a detached session is handled by the domterm backend, which therefore needs to run remotely. However, the part that manages windows and commands needs to run locally.

The solution is to run the backend in proxy mode. Supposed the user types:

domterm [user]@host command

This can be implemented bying having the (local) backend do:

ssh [user@]host domterm --browser-pipe command

(A password may have to be requested.) The --browser-pipe option is a special kind of window-specifier: Instead of output being sent to the browser, it is written to stdout; input from stdin is (mostly) sent to the command. (“Mostly” because the remote domterm processes certain escape sequences. For example the "WS" sequences is used to change the pty window size.)

The local domterm backend acts as a proxy for the remote backend.

It is also useful to be able to connect to a remote backend, directly from a browser, without having to install a local domterm command. That requires a remote https server, and has some more permission and security complications.

Documentation

Create screencasts, maybe using Peek, or Byzanz. Consider using key-mon (available on Fedora) to display clicks etc.