[ On Tuesday, February 29, 2000 at 02:27:30 (-0500), der Mouse wrote: ]
> Subject: Re: ^W killed my line
>
> 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.

Actually in modern "readline", "libedit", etc., the command-line editor
is usually a multi-line editor that just happens to have a one-line
"window".

> 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.)

Ah, ha!  OK, I can certainly respect that.

The problem with choosing defaults in user interfaces is that the "safe"
default for one group of users might not be "safe" for another.

I don't know how to resolve this in general.  What I've done is to
carefully craft a set of personal configuration files that are also
portable to all of the unix-like environments I use.  These files
attempt to ensure that all the tools I'm bound to use will be in the
mode I expect them to be in at all times.  Obviously this is an
imperfect and ongoing process....

> 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.

I think my point is that applications (including /bin/sh) that offer
command-line editing cannot be expected to always honour the stty
settings when they are in "edit" mode.

I agree that if you expect stty settings to prevail by default then
command-line editing must be turned off by default.

This is in effect a close cousin of the AT&T philosophy that kept ERASE
and KILL set to "#" and "@" respectively by default all of these years.

I must admit that I did once present a case suggesting that GNU Emacs
should honour ERASE (though only ERASE! ;-).  However I had an ulterior
motive and indeed my goals were fulfilled without actually having to
have GNU Emacs peek at the stty settings.

> 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.

Ah ha.  I see.  I've never used job control that way.  Indeed I've been
using windowing systems long before I used X11 and I've almost always
agreed with the idea that job control should only be handled in the
windowing system, not in the tty driver.  When I do suspend a job it's
usually only to put it into the background after I forgot to use '&'.
I've never found a desire to suspend a job on completion.

> 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....

There's the option, as you suggest, of doing it in a front-end processor
(eg. the windowing system).  I've always wanted to do more than just
cut&paste in an xterm for example (especially searching, like I can do
on my DMDs!).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>