The article at https://opensource.com/article/18/1/introduction-domterm-ter... is a good overview of what DomTerm is about. I've long been interested in how we can improve terminals/REPLs/consoles - I wrote the Emacs term mode in attempt to integrate shell mode with a real terminal emulator (though the attempt to replace shell mode did not "take").
(I reposted at the encouragement of moderator Daniel - thanks!)
Some of the things I've been working on since the opensource.com article include:
- better input editing: most of the functionality of readline with mouse/selection/clipboard integration. Main thing to be worked on is command (tab-) completion. I'm mulling the best way to do that.
- more generally, I want the functionality of UpTerm/FinalTerm. But writing out own shell is a mistake (well, I'm thinking about that, too ...). Better to use an existing shell - possibly fish as it has builtin auto-completion.
I am pleased with the current ascendancy of Jupyter notebooks, interactive sessions of data manipulation.
When I first encountered Mathematica notebooks in early 1990s, I thought that this would be the way forward. A few years later, XMLTerm with Mozilla.. and it doesn't find an audience.
I was thinking of an uncanny valley between CLI and GUI, but I am writing this in a web browser on an iPad, which is better than any interaction paradigm we might have held in 1990.
We need more work on DOMTerm, notebook-style interaction design. I'm a bit surprised that Windows PowerShell does not play in this space.
> But writing out own shell is a mistake (well, I'm thinking about that, too ...). Better to use an existing shell - possibly fish as it has builtin auto-completion.
Maybe consider xonsh shell [1].
» Xonsh is a Python-powered, cross-platform, Unix-gazing shell language and command prompt. The language is a superset of Python 3.4+ with additional shell primitives that you are used to from Bash and IPython. It works on all major systems including Linux, Mac OSX, and Windows. Xonsh is meant for the daily use of experts and novices alike. «
XMLTerm was an inspiration to me, and you can think of DomTerm as my attempt to combine the ideas of XMLTerm (graphics, logical structure of output, smart interaction) with a solid xterm-compatible terminal emulator. The most important difference is that XMLTerm is long dead! (However, XMLTerm's author more recently wrote GraphTerm as a more modern take on XMLTerm - however, that too is unmaintained.)
Based on trying Hyper out (a version from April), and the web-site, I can list these differeences. (I could be wrong about them, and I'm sure Hyper has other nifty features, perhaps as an extension.)
Applications under DomTerm can "print" general html including images and rich text.
Hyper does worse on xterm/vtNNN compatibility, as indicated by running the vttest program.
Hyper does not re-flow long lines on window resize.
Hyper does not remember if TAB was used in output. (I.e. cat Makefile, then copy-and-paste contains spaces, not a tab.)
Both support splitting the window into panes, but hyper doesn't seem to support re-arranging using drag-n-drop.
DomTerm can run in a browser (as an alternative to Electron), and has buitlin session support (a la tmux/screen).
DomTerm has a builtin input editor (similar to GNU readline, but with mouse/selection/clipboard integration). By default (in "auto" mode) this is selected by on the pty canon/raw state.
DomTerm keeps track of "logical" structure of the output, aided by special PROMPT escape.
DomTerm lets you right-click on an FILENAME:LINE:COLUMN in an error message, and can open your preferred editor.
Hyper has an extension mechanism, which DomTerm does not (yet) have.
I wasn't able to run GateOne. (I tried the online demo - not there; building from source - a Python stacktrace; and I looked for prebuilt binaries.)
It looks like most of the code (including the escape sequence handling) is in Python. I gather most of the logic is server-side. While DomTerm has quite a bit of server-side code (basically the lws-term directory, written in C), the majority is JavaScript.
There was a bad (malicious) .htaccess file. I've removed it, but there remains the question of how it got there.
Added: The domterm.org directory in my home directory on DreamHost (from which domterm.org is hosted) was group and world-writable. Don't know how that happened (probably my carelessness), but I fixed it.
Second, now that we've got the terminal in a browser, we've got a linux subsytem for WebAssembly (https://github.com/cervus-v/cervus), and we've got QT for WebAssembly, we seem to be ~2 years out from someone pushing a real "web os" – as in an adult could probably boot to WebKit and perhaps not know that they're in a WebBrowser. Sure that's an opportunity for Google and Facebook to finally "compete" against the incumbent OS market.
The snake will inevitably eat itself again in some 30 year supercycle.
This is along the lines of the "birth and death of javascript" slides. But as it really is happening, are we really gaining anything? Anything at all?
And again, not to take away from DomTerm which seems really cool.
20 comments
[ 5.6 ms ] story [ 48.2 ms ] thread(I reposted at the encouragement of moderator Daniel - thanks!)
Some of the things I've been working on since the opensource.com article include:
- better input editing: most of the functionality of readline with mouse/selection/clipboard integration. Main thing to be worked on is command (tab-) completion. I'm mulling the best way to do that.
- more generally, I want the functionality of UpTerm/FinalTerm. But writing out own shell is a mistake (well, I'm thinking about that, too ...). Better to use an existing shell - possibly fish as it has builtin auto-completion.
- Menus (menubar and popup) for "generic" (non-Electron non-Qt) front-ends: http://per.bothner.com/blog/2018/jsMenus/
- better display of complex nested data, integrating show/hide buttons with pretty-printing, wih dynamic re-flpw on window re-size
I am pleased with the current ascendancy of Jupyter notebooks, interactive sessions of data manipulation.
When I first encountered Mathematica notebooks in early 1990s, I thought that this would be the way forward. A few years later, XMLTerm with Mozilla.. and it doesn't find an audience.
I was thinking of an uncanny valley between CLI and GUI, but I am writing this in a web browser on an iPad, which is better than any interaction paradigm we might have held in 1990.
We need more work on DOMTerm, notebook-style interaction design. I'm a bit surprised that Windows PowerShell does not play in this space.
Maybe consider xonsh shell [1].
» Xonsh is a Python-powered, cross-platform, Unix-gazing shell language and command prompt. The language is a superset of Python 3.4+ with additional shell primitives that you are used to from Bash and IPython. It works on all major systems including Linux, Mac OSX, and Windows. Xonsh is meant for the daily use of experts and novices alike. «
[1] http://xon.sh/
https://hyper.is/
Applications under DomTerm can "print" general html including images and rich text.
Hyper does worse on xterm/vtNNN compatibility, as indicated by running the vttest program.
Hyper does not re-flow long lines on window resize.
Hyper does not remember if TAB was used in output. (I.e. cat Makefile, then copy-and-paste contains spaces, not a tab.)
Both support splitting the window into panes, but hyper doesn't seem to support re-arranging using drag-n-drop.
DomTerm can run in a browser (as an alternative to Electron), and has buitlin session support (a la tmux/screen).
DomTerm has a builtin input editor (similar to GNU readline, but with mouse/selection/clipboard integration). By default (in "auto" mode) this is selected by on the pty canon/raw state.
DomTerm keeps track of "logical" structure of the output, aided by special PROMPT escape.
DomTerm lets you right-click on an FILENAME:LINE:COLUMN in an error message, and can open your preferred editor.
Hyper has an extension mechanism, which DomTerm does not (yet) have.
It looks like most of the code (including the escape sequence handling) is in Python. I gather most of the logic is server-side. While DomTerm has quite a bit of server-side code (basically the lws-term directory, written in C), the majority is JavaScript.
Added: The domterm.org directory in my home directory on DreamHost (from which domterm.org is hosted) was group and world-writable. Don't know how that happened (probably my carelessness), but I fixed it.
Second, now that we've got the terminal in a browser, we've got a linux subsytem for WebAssembly (https://github.com/cervus-v/cervus), and we've got QT for WebAssembly, we seem to be ~2 years out from someone pushing a real "web os" – as in an adult could probably boot to WebKit and perhaps not know that they're in a WebBrowser. Sure that's an opportunity for Google and Facebook to finally "compete" against the incumbent OS market.
The snake will inevitably eat itself again in some 30 year supercycle.
This is along the lines of the "birth and death of javascript" slides. But as it really is happening, are we really gaining anything? Anything at all?
And again, not to take away from DomTerm which seems really cool.