>> Or people who use stty to change their tty characters and are silly
>> enough to expect that the change will actually take effect.
> Ah, why would anyone expect that changing the tty line edit
> characters would have any effect on a character-oriented editor
> that's built into some application

The point is that it is fundamentally a line-oriented interface, so
(absent user configuration to the contrary) I expect, not unreasonably
I think, that it behave the way "everything else" with a line-oriented
interface does.

I like command-line editing -- when I ask for it.  (For me to ask for
it, it has to be configurable enough; I have yet to figure out how to
configure ftp or gdb to behave sanely for my definition of "sanely", so
I wouldn't turn on command-line editing for them.  The problem is, I'm
not given the choice - they come up with line editing on.  ftp at least
has a switch to turn it off, but that's the wrong default.)

> Would you really expect "stty werase :" to change vi's interpretation
> of ':'?

No; vi's interface isn't line-oriented, so I don't expect line-oriented
input editing to happen.  I *would* expect it to affect ed (and
arguably line-oriented subsets of visual programs, such as
non-open-mode ex or vi's : command-line, though these are a gray area).

> Yes there is some trickery with /bin/sh since it is fundamentally
> perceived to be tied to the very idea of command-line input.  However
> there's a big difference between "cat -u | sh" and "sh -E"!

Right.  I have no problem with sh, because I have to ask for
command-line editing to get it.  If I like it, I can use it; if I
don't, I can leave it off.  As it happens, I do often turn it on.

>> Why not just snip out stty's ability to set special characters,
>> since NetBSD obviously doesn't care about anyone who wants to
>> actually use that capability?!  (Or even, it appears, use some of
>> the defaults for their documented purposes, like ^W for word-erase
> I think you're hung up on the idea that the tty driver should be the
> one and only king of input editing.

I don't think so; I think you misunderstood.  This paragraph is about a
*human* point, not a *technical* one - "it works for me, so ship it",
without considering that not everybody uses eofc=^D, or suspc=^Z, or
whatever.  I submitted a PR about ftp when I first noticed the EOF
problem.  It was closed by someone who apparently read the one-line
summary, tried it (with eofc=^D), found it worked, and didn't bother
reading my "how to repeat" section which carefully said to use
something other than ^D.  This sort of "it works when I use the
standard settings, so it's not broken" attitude is what I'm actually
upset about here.

If you want ftp and gdb to have input line editing that enforces ^D as
the effective eofc, that's fine - PROVIDED it's turned off by default!

>> - or the dsuspc, something that's been broken for longer than I've
>> used NetBSD, and I keep meaning to figure out what's wrong with it.
>> I can only assume that *nobody* actually uses the dsuspc.)
> Most machines are fast enough these days (even a 486!) that I don't
> think anyone cares about the difference between DSUSP and SUSP.

I don't know what planet you're from, but I still have plenty of
commands that take longer than fifteen seconds to complete.  The
fastest NetBSD machine I've ever used still took over an hour to "make
build".  And I relatively often do over-the-net compares which I would
like to auto-suspend things upon completion of - exactly the sort of
thing the dsuspc is designed for.  Yet I don't think I've seen an OS
dsuspc has worked on in the last decade, not since mtXinu 4.3+NFS and
possibly not even there - I forget.

>> Yes, I'm annoyed.  Very much so.  This linking libedit into
>> everything and its dog is rapidly becoming a right royal pain.
> Many folks, including myself, look at this in quite the opposite way!

Obviously.  And what I'm upset about is those folks forcing their idea
of how to do line editing down my throat.  (It is *almost* enough to be
able to "echo edit off > ~/.editrc", but (a) I shouldn't have to do
anything special to get standard input line editing, and (b) I'm still
screwed in single-user mode.)

> Indeed I find it somewhat wasteful that all the extra baggage from
> "newcrt" was codified (in a new and different way, of course!) in the
> termios "standard" (even though I was quite happy about it at the
> time! :-).  With libedit in enough applications we could probably
> ditch it all again and go back to the much more basic V7 style tty
> line discipline.

You would really compel every program author to deal with the editline
API in order to get rudimentary command line editing??  And talk about
a portabilityi nightmare....

> I don't really know where the economy lies, but I would rather see
> more complex input editing functions in the applications than in the
> tty code, especially if they can all share code from the same
> library.

The way sh shares it with ftp and gdb?  Right.  I foresee serious bloat
in /bin down that road.

I would much rather let people who want all-singing all-dancing command
line editing do it with a user-land front-end, for which hooks would
exist in the tty driver.  Indeed, most of the necessary support is
already there; I've seen programs that provide line-editing front ends
to any command-line application.  Add a little smarts, possibly some
hooks, for process groups (to distinguish history lists between
applications) and it sounds a lot like what you want.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B