[TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell)

[Marshall Conover <marzhall.o@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4937 bytes --]

Along these lines but not quite, Jupyter Notebooks have stood out to me as
another approach to this concept, with behavior I'd like to see implemented
in a shell.

With these notebooks, users type text into blocks, and then can have these
blocks evaluated by some underlying engine, with the results of the
evaluation showing up in a block underneath where they entered text.
Results can be not only text, but things like rendered charts and images.
There may be GUI-interactable rendered elements as well, but I'm unsure.

Notably, text-entry blocks are created such that each new block holds onto
the context of the previous blocks. So, a variable defined in the first
eval block will be available in later blocks.

Currently these are used primarily for demonstrating APIs, exploring data
with python, or writing quick PoCs that can then be extracted into an
application. Some companies, such as Netflix, have experimented with using
them entirely as a replacement for shell scripts, which is the sort of
research I'd most love to see.

Fundamentally, I think it's a smell that the way we interact with our
systems is tied to the long-gone hardware requirement of "be usable with a
teletype."  Acme was certainly a move towards recognizing the value of
being able to reuse space that, in TTYs, would be 'dead' text. The ability
to evaluate commands in Acme, and the further inclusion of an underlying
evaluator that holds state by Jupyter were good steps forward, I think.

I'd love to see experimentation with a whole system that takes the jupyter
approach, with nested namespaces forming applications, combined with data
being held in "blocks" as well as code - much like acme opens and edits
files as well as letting you execute either them or snippets in them. I
think there's a chance something could be developed that would better fit
the way we interface with computers today, and the underlying engine
approach would move us toward the "everything speaks one language" design
we lost in the move from shells to standalone GUI applications.

Mostly, I'd be bummed to see yet another shell that pretends it's behind a
"glass teletype", to use the tongue-in-cheek term from "Ed Mastery", or
just continuing elaboration on that design, despite the fact I use shells
daily. It's the best we have now, but I feel like it's the way forward.

Cheers!

Marshall

P.S. - Kakoune is neat and I'm going to have to poke around at that, thanks
for pointing it out.

On Mon, Jan 2, 2023 at 3:03 PM Joseph Holsten <joseph@josephholsten.com>
wrote:

> On Fri, Dec 30, 2022, at 12:42, Sven Mascheck wrote:
>
> and in "ksh - An Extensible High Level Language" David Korn writes:
>
>    -  "Originally the idea of adding command line editing to ksh was
>    rejected in the hope that line editing would move into the terminal
>    driver." [2]
>
> [2] https://www.in-ulm.de/~mascheck/bourne/korn.html
>
>
> This phrase has haunted me for years. It’s so clearly the “correct”
> separation of concerns, until you actually attempt implementing it. And
> Bourne’s irregular grammar certainly doesn’t help here. I’d prefer to move
> beyond readline, ideally something like text objects per
> vim/zsh/treesitter. But having one parser in the interpreter and another in
> the line editor becomes quite exciting if you want a true bourne or even
> posix sh.
>
> But the thing that brought be back to playing against this quote again
> this year was starting to research the QED lineage and discovering helix &
> kakoune. Honestly, they feels like the most coherent advancements in
> QED-style editors since sam & acme. (Yes, I’m irrationally excluding vim
> text-objects, mostly because no one removed editor features that t-o made
> redundant. It’s as if ed had twice as many commands, one for regexp matches
> and one for pre-ken-QEDist exact matches.)
>
> Anyway, the only time I’ve really seen “line editing […] move into the
> terminal driver” sound possible was acme’s win. For those who haven’t had
> the pleasure, rsc describes it at 15:25 in https://research.swtch.com/acme.
> “I worked for many years in a shell without history or command line
> editing, and I never missed it because Acme is providing this for me.”
>
> It’s hard to convey how surprisingly pleasant sh or rc can be within acme
> win to someone who has only used them within a mere
> terminal-emulator-emulator. Especially since a greenfield terminal app
> has more code emulating old xterm behaviors than physical vt100 behaviours.
> This is especially exhausting when you try to use something like NeoVim’s
> :term expecting it to just work and discover that buffer-line-wrapping on
> window-resize hasn’t been implemented.
>
> Anyone seen any other “terminal drivers” that provide a pleasant
> alternative to line editing?
> --
> ~j
>

[-- Attachment #2: Type: text/html, Size: 6059 bytes --]