3 Jan
2023
3 Jan
'23
3:08 a.m.
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(a)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