Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!haven!adm!xadmx!dsill@relay.nswc.navy.mil
From: dsill@relay.nswc.navy.mil
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) kernels--what I think
Message-ID: <19834@adm.BRL.MIL>
Date: 1 Jun 89 14:44:53 GMT
Sender: news@adm.BRL.MIL
Lines: 33

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

> Commands should all use perror(), wherever possible.

I'd take it a step further and implement VMS-style configurable error
messages.  Let the user decide whether his error messages include the
gory details, only the text of the message, or anything in between.

>  The online help should be better.  Either an entirely new facility needs to
>  be added, or MAN needs to have better indexing.

This is already taken care of.  GNU will use the same TeX/Info format
for documentation that Emacs uses.  Last I heard, a stand-alone Info
browser was Almost Finished.  For the unfamiliar, this format allows
hardcopy manuals, using TeX, and on-line, tree-structured
documentation to be produced from a single file.

-Dave (dsill@relay.nswc.navy.mil)