ogilvie@utah-cs.UUCP (John Ogilvie) (11/29/83)
The command interpreter on the Lilith machine, which runs Modula-2, uses long names in connection with string recognition. So, for example, if I type "dir" and wait a second or two, the system fills in the rest to give "directory". I then hit <cr> and I'm off and running. In this way, I don't have to remember a lot of bizarre abbreviations like "grep" and "cat". Moreover, if I mistakenly type "rem" and wait for the rest of "remove", nothing happens. This reminds me that I'm not working with UNIX, so I type "del" and the system completes the command, "delete", for me. It is true that you can learn all the short commands, "~r filename" for instance to insert a file into the letter you're mailing, but why not make life easy on yourself? The method above is a sort of menu/command-language, where you type characters instead of choosing entries in a menu, and still get the feedback from the system, and needn't wait long. Incidentally, the Lilith also uses a bit-mapped display. The menus used in the text editor, for instance, take no appreciable time to appear. (No, I'm not on a commission or a mission). John Ogilvie (utah-cs)
ccc@cwruecmp.UUCP (Case Computer Club) (11/30/83)
------------------ I have one problem with your solution. A second or two is a LONG time! I have come to expect computers to be relatively fast, and for a system to come back several seconds later with the result seems ridiculous. If we want long command names, there is always command completion ala TOPS-20 or a modified c-shell. Carl Fongheiser decvax!cwruecmp!ccc (Usenet) ccc@Case (CSnet) ccc.Case@Rand-relay (ARPAnet)
davidson@sdcsvax.UUCP (12/03/83)
Command completion systems have been discussed extensively on the human-nets, editor-people and works digests, but let me briefly respond to the supposed advantages of the crude command completion system on the Lilith workstation. To abbreviate a Lilith command successfully, you must know any other command which might contain a common substring, or more simply, you must know how many characters you must type for each command, but be prepared to revise this knowledge every time a new command is created. Failure to know this either requires you to be conservative and type many more characters than you really need (and still not be guaranteed uniqueness) or to WAIT for feedback. I can't understand why a system which requires you to pause and wait for a completion (and wonder how long you have to wait, depending on system load!) can possibly be a win. (Yes, I know Lilith is a single user workstation, and you can learn how long you need to wait - assuming no significant background tasks are running - I still don't think much of it.) A better approach is the TENEX option of typing ESC when you think you've typed enough, or ? when you want to know your options. If when you type ESC you've not given enough characters, TENEX will beep at you (but if you've specified enough for it to guess the next few characters, it will type them for you instead). Typing ? gives you a list of the legal completions, although annoyingly it doesn't then let you just select one, but requires you to finish typing a unique command. Lots of variants of command completion systems exist. The fanciest systems type ahead of you automatically, and let you either type over the supplied text, or hit ESC or SP to skip to the end of the word or phrase and continue typing until the command is finished. I find the cognitive load needed to efficiently interact with completion systems rather high. I find systems which allow me to abbreviate names or phrases with regular expressions to be much easier. This feature is present throughout UNIX and its subsystems in contexts where a list of names is legitimate, but I know of no such systems where uniqueness is assumed, with a popup menu to handle multiple selections. Although completion systems and regular expression systems are convenient, I find short, abbreviated names much easier. Compare the following key- strokes: del<esc>ETE notesfiles.d<esc>OC <cr> /* TENEX */ rm n*.d* <cr> /* UNIX */ rm nf.me <cr> /* UNIX */ The first is clearly more cumbersome. The first two require considerable thought on the part of the user to guess how much to specify. Moreover, if the specification were not unique as intended, the first example would require further typing, and the second example would remove extra files! I much prefer the last, despite the reduced mnemonicity. -Greg