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

[Rob Pike <robpike@gmail.com>]

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

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]
>
> [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: 3987 bytes --]