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. «
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.
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.
[+] [-] Per_Bothner|7 years ago|reply
(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
[+] [-] watersb|7 years ago|reply
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.
[+] [-] still_grokking|7 years ago|reply
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/
[+] [-] dfee|7 years ago|reply
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.
[+] [-] wolframhempel|7 years ago|reply
[+] [-] Per_Bothner|7 years ago|reply
[+] [-] ravitation|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] gcoda|7 years ago|reply
[+] [-] Per_Bothner|7 years ago|reply
[+] [-] jonny_eh|7 years ago|reply
https://hyper.is/
[+] [-] Per_Bothner|7 years ago|reply
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.
[+] [-] rkeene2|7 years ago|reply
[+] [-] smartmic|7 years ago|reply