Re: Es and autocompleting

[Steve Kilbane <steve@whitecrow.demon.co.uk>]

Dan asked:
> Could you expand on this belief?
> (Or point me at some place where you already have done so.)

While Paul's previous comments are probably on a list archive somewhere,
a fresh articulation might be good, since he's already admitted to one
shift in the last half-decade. :-)

FWIW, my own objections to completion are distinctly dodgy, but I'll
put them forth anyway:

- In a general-purpose UNIX shell, completion demands a lot of its
environment. It has to handle key characters specially beyond the usual
character/word deletion operations, and that raises the complexity both
of the read/execute loop and the porting process.

- It's something that is completely unnecessary in a non-interactive state.

- It's laziness; I like being able to type. :->

> It seems to me (probably naively) that the shell is in the best position
> to know the context of the current command, and therefore to be able to
> predict the set of possible choices.

Well, maybe. Things are a little different in Plan 9, where the path is
always just dot and /bin, but that can mean many different things. Similarly,
in a windowing system, the window environment multiplexes the keystrokes and
has to handle the edit stream, so why not let it do the completion magic too?
It can also provide history, do so across different windows for a single
history file, and maybe even provide other command mechanisms, too. As a
minor example, I once had a hacked version of 9term that would receive commands
from a pipe and forward them to the shell.

steve