This means supporting all the “base” functionality
of xterm as implemented by terminal emulators that
At this point we’re pretty close to that.
Error recovery and state transitions should follow this.
Other terminal emulators:
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.
The xterm distribution includes vttest. Many of the tests work now, but there are more worth fixing.
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.
<canvas> element could be used.
A “word” that has the form of a URL or that start with “
should be handled as an “implicit link”: Hovering over them styles
them as links, and clicking them opens the URL.
The same should be done with email addresses.
Handle exporting html to clipboard.
Fix paste in line-editing mode.
Think about how to do multi-line paste.
Handle saving and truncating scrolled-out output.
qtdomterm supports tabs, moving a tab from from
one window to another window does not work.
Implement “drop-down” mode.
Some toolkits to explore for integrated browser/application:
The idea is the line-editing mode would provide the functionality of readline or similar programs.
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).
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.
similar to the way Emacs
term mode does it.
When enabled, after a full screen of output without user interaction, further output is queued until the user requests more output. This should be integrated with searching in the buffer.
Allow processes to send HTML and graphics to DomTerm. See some previous work: http://per.bothner.com/blog/2007/ReplPane/
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.
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 format must be XML-compatible (XHTML) so it can be parsed by XML tools such as XSLT.
Specific format TBD.
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.
GNU Screen and Tmux handle multiple terminals. They provide keystroke bindings that make it convenient to create new terminal jobs, and navigate between them. This isn’t a critical feature, since people can always using windows and tabs, but it would be nice.
The dtvm project implements tiling window management for a terminal emulalot (without session management).
The Split.js library could be useful for implementing tiling.
Ideally, tiling should be handled by a window manager and/or a library. I love the flexibility and ease-of-use of how NetBeans handles windows, tiling, and tabs, with a great drag-and-drop mechanism.
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
Using QtWebEngine in headless mode makes sense if we also use qtdomterm.