It just seems much more natural to me to have line editing provided at some fundamental level. Putting it in the shell or some library means some tools get it but some don't. Why should sh have editing but mail not? But then there's glob.

Do it once, do it well, and do it for everything, where "it" is a wildcard that refers to every important detail.

-rob


On Tue, Jan 3, 2023 at 7:03 AM 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