more ksh fixes (ESC ESC in emacs mode)
Charles Hedrick
hedrick at aramis.rutgers.edu
Wed Jun 29 03:18:27 AEST 1988
I am reluctant to get into an argument about taste. I can only say
that Tenex, TOPS-20, various variants of csh, Emacs, and the newest
version of ksh (not yet in the toolchest) all agree that completion of
a file name simply means just that: completion. If it is impossible
to provide a unique completion, they beep. Actually TOPS-20 is
stricter than the Unix software. If there is more than one
alternative, TOPS-20 will just beep, whereas the Unix software will
generally complete that portion on which they all agree. (However
there are provisions in TOPS-20 for completing the base name even if
there is more than one extension.) E.g. if you have aaabbbccc and
aaabbbaaa, and you type aaa<ESC>, most Unix completion software will
supply the bbb and then beep. Many of us have gotten used to this
behavior and depend upon it. E.g. the Emacs that I use renames the
original of an edited file to foo.BAK. So it's common that I have
aaa.c and aaa.c.BAK. If I type aa<ESC>, it will complete to aaa.c and
then beep. I do not want to see both aaa.c and aaa.c.BAK, which is
what the original ksh code did. Similarly, if I have verylongname.c
and verylongname.o, and I type very<ESC>, it should complete to
verylongname., thus requiring me to type only .c or .o. Completion
seems to have been invented in the first place to help users type
the long command and file names allowed by Tenex. Since many of those
long names exist with multiple extensions, we really do want partial
completion, not enumeration of the alternatives. Obviously there are
uses for both behaviors, which is why the new ksh code continues to
provide the original behavior under ESC *.
More information about the Comp.unix.microport
mailing list