Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!think!husc6!spdcc!lexicon!rk
From: rk@lexicon.com (Bob Kukura)
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) kernels--what I think
Message-ID: <445@lexicon.com>
Date: 1 Jun 89 18:52:09 GMT
References: <19834@adm.BRL.MIL>
Organization: Lexicon, Inc., Waltham, MA
Lines: 47
In-reply-to: dsill@relay.nswc.navy.mil's message of 1 Jun 89 14:44:53 GMT

In article <19834@adm.BRL.MIL> dsill@relay.nswc.navy.mil writes:

> >From: Marcus Leech <ml@gandalf.uucp>
> >
> > Options should be complete words, with a minimum-unambiguous scheme
> > to reduce typing.
> 
> I'd prefer Twenex COMND JSYS style help/completion, which, for those
> not familiar with it, allows partially-typed commands and options to
> be completed, as long as they're unique, by pressing a single key.
> Another key lists possible completions.  I've used systems that allow
> (necessitate) abbreviations (VMS, MS-DOS, AmigaDOS), provide command
> completion (TOPS, Emacs, tcsh), and a couple that do neither (sh,
> csh).  I much prefer completion to abbreviation because completion
> provides feedback, preventing me from typing a long complicated
> command only to discover one or more ambiguous abbreviations.  With
> completion, I'm much more confident that that the command will work
> right the first time.
> 

I would like to see some sort of extension to command completion that
enabled shells to complete not only the command name, but option
names, file names, and anything else in the command line.  Each word
would be completed in exactly the context in which the command would
use it.

One approach to this would be to replace the argv mechanism with some
sort of interactive scheme.  A shell would start up an application as
soon as its command name was successfully completed, and then would
communicate with the application using some protocol to determine the
namespace from which completion alternatives for each argument come,
and to validate the actual arguments as they are entered.  Finally,
when all the arguments are negotiated, the shell would tell the
application to go do its thing.  Of course, there would also have to
be a non-interactive method of invoking all commands.  Maybe a single
command-line option would be reserved for all commands that would
cause them to enter this interactive protocol to get their arguments.

Maybe GNU should support some even more general mechanism for
communicating with users that would provide consistent editing,
completion, and history features in all contexts.  Does this sort of
thing belong in the kernel?  The shells?  The window system?  The
libraries?  The tty driver?
-- 
-Bob Kukura		smart: rk@lexicon.com
			dumb: {husc6,linus,harvard,bbn}!spdcc!lexicon!rk
			phone: (617) 891-6790