From: utzoo!decvax!cca!Zellich@OFFICE-3@sri-unix Newsgroups: net.works Title: Re: End User Interface a la Augment/NLS Article-I.D.: sri-unix.2246 Posted: Fri Jul 23 05:34:40 1982 Received: Mon Jul 26 00:09:39 1982 True, you may have problems if you drastically change commands; this has zapped us a few times in using Tymshare's evolving version. It helps a lot though, if you advertise the "gotcha" type changes when you field the new release. Note that the Augment/NLS interface uses \full words/ in command files, rather than single command-characters. Thus, the command files are not at all cryptic, and tend to just bomb out rather than doing the wrong thing if the command language changes and you forget to update a command file. There is no real problem renaming commands with the Augment/NLS user interface (if the particular program is designed that way - the "regular" subsystems aren't). The grammar parser is working from a table describing what is to be collected from the user next, and what to do with it. It allows not only literals in the command table, but also variables and list-variables. Thus, in some of our subsystems, we have allowed the users to change the standard command words by simply carrying them as useroptions and stuffing the words into a list structure which is passed into the grammar-table environment. You still have the problem of a particular user not thinking too clearly and defining duplicate command words, but that can be checked for in the "Define" (or "Rename" or "Change Command-word", or whatever you want to call it) command. You could \also/ check for first-letter duplicates, and warn the user if you wanted to, so multiple characters wouldn't be required to invoke the duplicate commands. There are problems possible with single-character command invocation, but you can solve most, if not all, of them by careful design. Cheers, Rich -------