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]

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