6 ms·

Richer command line interfaces

160 points by nreece 10y ago

RivieraKid 10y ago
I've been thinking about something similar, that there should be a richer command line interface platform rethinked from the ground up. For example, it could support images or mouse input, which is one reason why web-based shells like Jupyter exist. Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility (with SSH etc.).
- deleted 10y ago
  [deleted]
- adrianratnapala 10y ago
  Of course SSH compatibility is still a useful feature. Unlike vt220 compatability -- which is the real thing that kept terminals back. Also SSH is not an impediment: it's a byte-pipe so as long as your graphical shell is serialisable, SSH should be fine. (Although we might want to replace it with something like Mosh (https://mosh.mit.edu/ https://mosh.mit.edu/) for other reasons).
  - visarga 10y ago
    Mosh is great but it doesn't handle scrolling too well, and when I do development I usually need to scroll back to see the program results.
    - icebraining 10y ago
      You can use Mosh + Screen (or Tmux, I suppose) to get a scrollback.
- city41 10y ago
  iTerm2 supports inline images, and basically all terminals support mouse input.
- mrob 10y ago
  IMO the biggest problem with terminals is poor input handling. Many useful key combinations are impossible to type. Paul Evans has a proposal for fixing this, but it seems to be mostly ignored: http://www.leonerd.org.uk/hacks/fixterms/ http://www.leonerd.org.uk/hacks/fixterms/
- icebraining 10y ago
  There was the TermKit proposal: https://acko.net/blog/on-termkit/ https://acko.net/blog/on-termkit/
- yrro 10y ago
  I remember seeing some amazing things in a video of a LISP-based shell & 'terminal emulator' many years ago. Unfortunately I can't remember what it was called... but as far as I remember, it was full of inline images & animations and listing a directory would include icons to indicate the file type, which could be clicked on to open a file manager, etc.
  - vertex-four 10y ago
    There were, of course, the lisp machines - Open Genera etc - which did a lot of that.
  - wtbob 10y ago
    Sounds a little like CLIM, e.g. https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html
  - junke 10y ago
    Symbolics Lisp Machine demo Jan 2013, Kalman Reti https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
  - lfowles 10y ago
    The Plan 9 terminal emulator[0] was pretty neat the last time I used it (probably 8 years ago now). I seem to remember the TempleOS terminal[1] being pretty unique as well, but I don't remember exactly why. [0] http://www.cs.usyd.edu.au/~matty/9term/ http://www.cs.usyd.edu.au/~matty/9term/ [1] http://www.templeos.org/ http://www.templeos.org/
    - rsync 10y ago
      TempleOS shell is a real-time C compiler/debugger that you can write and execute C programs in ... and ... something ?
- Ruud-v-A 10y ago
  > Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility The TempleOS shell is pretty innovative in this regard.
- swiley 10y ago
  I don't want mouse input in the shell, half the reason I use it is to avoid the mouse. You could have it with current VTEs though, GPM works just fine and I use it with vim.
- gaius 10y ago
  Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility It would look pretty much like it does now. If you look at any professional software, that people spend their entire working day in, it tends to avoid any fancy stuff and rewards those who take the time to learn it (because they have to, because its their job) with superior productivity through keystroke shortcuts that take advantage of muscle memory. People forget that technical development is bidirectional. Yes you make the best you can with the components available to you - but those components didn't come from nowhere, they were all made by people to solve their own problems, so what's possible and what's ideal eventually converge. The major leap forward in terminals was to be able to have many of them open at once on your X11 display. It's done, problem solved. Even Apple who can't resist GUI-ing everything have kept the Terminal.app simple.
- philipswood 10y ago
  Check out the Oberon OS TUI sometime. https://en.m.wikipedia.org/wiki/Oberon_(operating_system)#User_interface https://en.m.wikipedia.org/wiki/Oberon_(operating_system)#Us... (Oberon's GUI represents one of the paths not followed by mainstream computing-a non WIMP approach) couple of notable features. Tiled, not overlapping windows. All three mouse button combinations have meaning (select, copy & paste can be done without a keyboard). Any text can be higlighted and executed. GUI approach is document based, with everything a text and texts being mostly, um, textual... I cant find a nice writeup to link to, but there used to be a vm available.
  - mrob 10y ago
    3-button mouse operation seems underused in modern OSes. I miss the "adjust" mouse button in RiscOS. It made changes with the minimum possible state change, eg. adjust-dragging a window would move it without changing the z-order, and adjust-clicking menu items would click the menu item without closing the menu.
nojvek 10y ago
A shell with a great auto-complete and rich input would be killer. I've been using black screen and really like it. Although they use too much whitespace for my liking.
grewil2 10y ago
It looks similar to company-mode ("complete anything mode") in GNU/Emacs, which works in shell buffers as well. https://company-mode.github.io/ https://company-mode.github.io/
voaie 10y ago
A new engine: https://github.com/withoutboats/notty https://github.com/withoutboats/notty
forgotpwtomain 10y ago
I end up using the mouse + terminal(copy/paste hotkeys) quite often for git add after a git status. It's usually faster to highlight+copy/paste than it is to auto-complete on a nested file. I've often thought that there should be a better/faster interactive way to reference existing output in the next command.
- lfowles 10y ago
  With intelligent highlighting on double click, mouse is so much faster for small one-off operations like that. I wish CLI users/devs/ranters weren't so hostile to the thought of using more than a keyboard...
wbl 10y ago
These features are what I use emacs terminal for. What we need are dumber programs and smarter terminals, like Plan 9 had.
- jxy 10y ago
  With acme, most of the time I only need to 2-click any shell code that I assembled in a scratch file/window, then a new window opens with the output. We perhaps don't need smarter terminals either. Look at it in an abstract way, all we need is an easy way to (a) pass a command to some program and (b) display its output. For (a), acme's input to rc through 2-click is really simple and effective, although it's only for text; but for (b), if we want to include anything more than text, nowadays browsers work in such a way, but we need orders of magnitude faster processors to make it usable. I'll stick with text and acme for now.
- cpu 10y ago
  Right on the money. curses needs to die and we need to make better use of our resources. It's eye-opening to explore these projects that "never caught on" even though they had great ideas that we still don't see today. (Granted, those projects truly never gained popularity for other reasons.) I'm glad to see that there are others thinking about these things. The current state of things bothers me enough that I will do something about it, but I'm afraid that I am something of an extremist and that my particular solution won't satisfy many other people. Because of this, I expect more popular alternatives to arise while I am hacking my own.

160 points by nreece 10y ago

I've been thinking about something similar, that there should be a richer command line interface platform rethinked from the ground up. For example, it could support images or mouse input, which is one reason why web-based shells like Jupyter exist. Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility (with SSH etc.).

deleted 10y ago
[deleted]
adrianratnapala 10y ago
Of course SSH compatibility is still a useful feature. Unlike vt220 compatability -- which is the real thing that kept terminals back. Also SSH is not an impediment: it's a byte-pipe so as long as your graphical shell is serialisable, SSH should be fine. (Although we might want to replace it with something like Mosh (https://mosh.mit.edu/ https://mosh.mit.edu/) for other reasons).
- visarga 10y ago
  Mosh is great but it doesn't handle scrolling too well, and when I do development I usually need to scroll back to see the program results.
  - icebraining 10y ago
    You can use Mosh + Screen (or Tmux, I suppose) to get a scrollback.
city41 10y ago
iTerm2 supports inline images, and basically all terminals support mouse input.
mrob 10y ago
IMO the biggest problem with terminals is poor input handling. Many useful key combinations are impossible to type. Paul Evans has a proposal for fixing this, but it seems to be mostly ignored: http://www.leonerd.org.uk/hacks/fixterms/ http://www.leonerd.org.uk/hacks/fixterms/
icebraining 10y ago
There was the TermKit proposal: https://acko.net/blog/on-termkit/ https://acko.net/blog/on-termkit/
yrro 10y ago
I remember seeing some amazing things in a video of a LISP-based shell & 'terminal emulator' many years ago. Unfortunately I can't remember what it was called... but as far as I remember, it was full of inline images & animations and listing a directory would include icons to indicate the file type, which could be clicked on to open a file manager, etc.
- vertex-four 10y ago
  There were, of course, the lisp machines - Open Genera etc - which did a lot of that.
- wtbob 10y ago
  Sounds a little like CLIM, e.g. https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html
- junke 10y ago
  Symbolics Lisp Machine demo Jan 2013, Kalman Reti https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
- lfowles 10y ago
  The Plan 9 terminal emulator[0] was pretty neat the last time I used it (probably 8 years ago now). I seem to remember the TempleOS terminal[1] being pretty unique as well, but I don't remember exactly why. [0] http://www.cs.usyd.edu.au/~matty/9term/ http://www.cs.usyd.edu.au/~matty/9term/ [1] http://www.templeos.org/ http://www.templeos.org/
  - rsync 10y ago
    TempleOS shell is a real-time C compiler/debugger that you can write and execute C programs in ... and ... something ?
Ruud-v-A 10y ago
> Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility The TempleOS shell is pretty innovative in this regard.
swiley 10y ago
I don't want mouse input in the shell, half the reason I use it is to avoid the mouse. You could have it with current VTEs though, GPM works just fine and I use it with vim.
gaius 10y ago
Basically, I wonder what would a shell look like if it was designed today without any concern for compatibility It would look pretty much like it does now. If you look at any professional software, that people spend their entire working day in, it tends to avoid any fancy stuff and rewards those who take the time to learn it (because they have to, because its their job) with superior productivity through keystroke shortcuts that take advantage of muscle memory. People forget that technical development is bidirectional. Yes you make the best you can with the components available to you - but those components didn't come from nowhere, they were all made by people to solve their own problems, so what's possible and what's ideal eventually converge. The major leap forward in terminals was to be able to have many of them open at once on your X11 display. It's done, problem solved. Even Apple who can't resist GUI-ing everything have kept the Terminal.app simple.
philipswood 10y ago
Check out the Oberon OS TUI sometime. https://en.m.wikipedia.org/wiki/Oberon_(operating_system)#User_interface https://en.m.wikipedia.org/wiki/Oberon_(operating_system)#Us... (Oberon's GUI represents one of the paths not followed by mainstream computing-a non WIMP approach) couple of notable features. Tiled, not overlapping windows. All three mouse button combinations have meaning (select, copy & paste can be done without a keyboard). Any text can be higlighted and executed. GUI approach is document based, with everything a text and texts being mostly, um, textual... I cant find a nice writeup to link to, but there used to be a vm available.
- mrob 10y ago
  3-button mouse operation seems underused in modern OSes. I miss the "adjust" mouse button in RiscOS. It made changes with the minimum possible state change, eg. adjust-dragging a window would move it without changing the z-order, and adjust-clicking menu items would click the menu item without closing the menu.

nojvek 10y ago

A shell with a great auto-complete and rich input would be killer. I've been using black screen and really like it. Although they use too much whitespace for my liking.

grewil2 10y ago

It looks similar to company-mode ("complete anything mode") in GNU/Emacs, which works in shell buffers as well. https://company-mode.github.io/ https://company-mode.github.io/

voaie 10y ago

A new engine: https://github.com/withoutboats/notty https://github.com/withoutboats/notty

forgotpwtomain 10y ago

I end up using the mouse + terminal(copy/paste hotkeys) quite often for git add after a git status. It's usually faster to highlight+copy/paste than it is to auto-complete on a nested file. I've often thought that there should be a better/faster interactive way to reference existing output in the next command.

lfowles 10y ago
With intelligent highlighting on double click, mouse is so much faster for small one-off operations like that. I wish CLI users/devs/ranters weren't so hostile to the thought of using more than a keyboard...

wbl 10y ago

These features are what I use emacs terminal for. What we need are dumber programs and smarter terminals, like Plan 9 had.

jxy 10y ago
With acme, most of the time I only need to 2-click any shell code that I assembled in a scratch file/window, then a new window opens with the output. We perhaps don't need smarter terminals either. Look at it in an abstract way, all we need is an easy way to (a) pass a command to some program and (b) display its output. For (a), acme's input to rc through 2-click is really simple and effective, although it's only for text; but for (b), if we want to include anything more than text, nowadays browsers work in such a way, but we need orders of magnitude faster processors to make it usable. I'll stick with text and acme for now.
cpu 10y ago
Right on the money. curses needs to die and we need to make better use of our resources. It's eye-opening to explore these projects that "never caught on" even though they had great ideas that we still don't see today. (Granted, those projects truly never gained popularity for other reasons.) I'm glad to see that there are others thinking about these things. The current state of things bothers me enough that I will do something about it, but I'm afraid that I am something of an extremist and that my particular solution won't satisfy many other people. Because of this, I expect more popular alternatives to arise while I am hacking my own.