Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!rochester!udel!princeton!njin!aramis.rutgers.edu!hedrick From: hedrick@aramis.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.microport Subject: Re: more ksh fixes (ESC ESC in emacs mode) Message-ID: Date: 28 Jun 88 17:18:27 GMT References: <1616@hoqax.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 24 To: twb@hoqax.UUCP 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, 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, 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, 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 *.