Re: mail(1) editline defaults to vi mode?

[David Holland <dholland-tech%netbsd.org@localhost>]

(sorry about the long reply latency)

On Sat, Feb 18, 2023 at 07:46:24PM -0500, Mouse wrote:
 > >> I think that input line editing, no matter how fancy, should be
 > >> invisible to simple applications, as invisible as erase and kill
 > >> processing is for applications that run in cooked mode today.  [...]
 > 
 > > Ultimately the problem is that teletypes are baked into the core
 > > architecture of Unix and all more sophisticated user interaction has
 > > been bolted on top instead of being redesigned in.
 > 
 > I agree and I disagree.
 > 
 > If by "teletypes" you mean "octet streams", well, it might be an
 > overstatement to say that "everything is an octet stream" is the
 > unifying concept that has made Unix Unix, but not by much.  I'm not
 > sure I'd call that "the problem", though.

No, I mean "teletypes". The reasons we can't have real input line
editing except as a bolt-on library are:

 - Real editing, as opposed to cooked mode, requires terminal control
operations. But the abstraction in the kernel is a teletype, not a
terminal, and it doesn't have any such concept as terminal control.
Because termcap and then curses got bolted on top of the teletype
layer, you can't have its concepts _in_ the teletype layer.

 - Editing also requires, or at least strongly desires, cursor keys
and other function keys beyond typing single characters on a teletype
keyboard. But similarly, because termcap and curses got bolted on top
of the teletype layer, those concepts are not available in the
teletype layer either. Furthermore, because input handling in curses
has always been rubbish, the world is full of application code that
does its own input interpretation; the situation is far worse than
with output.

 - And then, completion and history are application-level functions,
so they inherently can't be done in the teletype layer, or any other
system-level input layer. Instead, the input read by the application
has to have enough structure that the application can read and go
"aha, the input layer has sent me this much and wants completions for
the rest", or "aha, the input layer is asking for history entry 72,
let me send it off". But because everything other than typing single
characters on a teletype keyboard got bolted on top, there's no
straightforward way to have that structure that doesn't interfere with
other things that might be happening.

 - It only gets worse if you start considering that there might be
other ways to produce input that have different semantics from typing
(e.g. under normal circumstances if you paste you are intending to
paste text and not editing operations; and also, input from dictation
has different editing requirements), or additional functionality
beyond completion and history (such as autocorrect).

These reasons are obviously addressable -- at least some of them
should have been addressed forty years ago or more, and it's been at
least thirty since cooked mode became clearly inadequate -- but they
require making fundamental changes.

And that's just for input line editing for programs that are still
basically using standard input. It only gets more complicated when you
also have screen-mode programs and GUI programs and whatnot. And then,
today the consoles of computers have a lot more functionality than
typing ASCII characters. Quite apart from GUI programming and video,
there's also pointing devices, stylus or other drawing-type input,
assorted HID objects, stuff you plug into the front panel like
scanners and cameras, and audio... along with stuff that Unix
basically just doesn't handle at all like GPS/location services,
accelerometers, or battery state. All of this ought to be available
systematically as input to applications (or not, depending on
permissions) rather than a mess of ad hoc devices and libraries. But
that's not what we have; we have teletypes.

 > The very notion of a command line owes a good deal to that unifying
 > principle, it seems to me.  I was never fortunate enough to use
 > interactive OSes designed without Unix available to draw on (while it
 > is just an assumption on my part that such exist, it seems likely).

Well, there were quite a few; e.g. RT-11 and RSX-11 (which eventually
grew into VMS), not to mention assorted mainframe horrors; plus the
BASIC interpreter UIs of the 8-bit machines. I'm not sure where CP/M
stood. MS-DOS ultimately had a notion of standard input, but I don't
know/remember how early it appeared; but applications that had user
interfaces tended to ignore it, just as they ignored DOS's standard
output and wrote directly to the video card. Then there's MacOS
Classic, but it never had anything resembling a command line of any
kind.

(Even today, Unix with curses or readline and whatnot is still, from
the point of view of an application wanting to have a user interface
and take input, largely a regression from the MS-DOS environment.)

Anyway, one of the ways Unix was different is that the shell wasn't
magic or privileged, and that does owe a great deal to the concept of
standard input.

 > > By the time you fix it, it's not Unix any more.
 > 
 > Depending on what the "it" is.  If it's the octet-stream unifying
 > principle, then, yes, eliminating, or even substantially changing, that
 > will break what makes Unix Unix.
 > 
 > But, if we assume the existence of an interactive command line?  I'm
 > not so sure.

You can certainly have a command line that's nothing like Unix. But
that's not what I meant. What I meant was that by the time all of
these input and console-related issues get sorted out into any kind of
coherent abstraction-based design, the resulting abstractions are
things Unix never had and work in ways Unix never anticipated.

-- 
David A. Holland
dholland%netbsd.org@localhost