Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote <tab>`, a listing shows all of the possible commands, such as `add` or whatever. Just make the console smarter, _with good algorithms that aren't slow_, and people would use it a lot more.
On the plus side, by picking and choosing what you want, you can get the precise performance and usability ratio that fits you best. Fish is a great shell but nothing beats the zsh plugin ecosystem.
Or in my case: spend a bunch of time messing with and tweaking my shell config. Sometimes the tyranny of default options is helpful to getting things done.
Do you mean it just ships with support for a list of preset commands, or can it provide autocomplete for any command? (I have no idea how that could possibly work, mind)
Sure, but configuration is more powerful. I the shell a lot, I’m not going to choose a suboptimal solution for my use case just because of a little bit of configuration.
Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
PowerShell has this; all cmdlet parameters are parsed by the PowerShell environment, so you don't have to write argument parsing code over and over; parameters to cmdlets are a standard form with many using the same common names where it makes sense.
Because of that design they are long and readable words but tab completable, and ctrl-space will bring up a menu of available matches starting with what you've typed so far.
Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen.
This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered.
[...]
Escape Recognition, Noise Words, Help
One of the most favored features among TOPS-20 users, and one most identified with TOPS-20 itself, is "escape recognition". With this, the user can often get the system to, in effect, type most of a command or symbolic name. The feature is more easily used than described; nonetheless, a brief description follows to aid in understanding the development of it.
A Brief Description of Recognition and Help
Typing the escape key says to the system, "if you know what I mean from what I've typed up to this point, type whatever comes next just as if I had typed it". What is displayed on the screen or typescript looks just as if the user typed it, but of course, the system types it much faster. For example, if the user types DIR and escape, the system will continue the line to make it read DIRECTORY.
[...]
Question-mark Help
Finally, if the user still isn't sure what input comes next in a command, he types question-mark, and the system will provide a list of choices that are legal at that point. The list includes specific keywords (e.g. FILE, DIRECTORY) and generic descriptions (e.g. "input file") Most importantly, the question-mark request does not destroy the previous command input. After the list of alternatives is displayed, the partial command is redisplayed, and input continues from the point just before where the user typed question mark.
As a result of this feature:
Users never have to go grab a manual and search around trying to find the name of a forgotten reserved word (command or parameter). This eliminates the "I know a word, can you guess it" aspect of many computer interfaces.
The user can often figure out from the choice of parameters what an unfamiliar command or option will do. This further eliminates laborious searching of manuals.
Because the context of the current command is not lost when help is requested, the user can go step-by-step through a command, figuring out each field in turn. In systems where getting help is a command itself, the user may have to write down a long unfamiliar command on a piece of paper in order to be able to enter it completely.
As menu-oriented interfaces have become more widely used, the advantage of having all choices visible to the user has become obvious. The question-mark help feature can, in retrospect, be seen as a "menu on demand" kind of approach, and it was one that worked even on terminals too slow to support full menu-based interfaces.
Origin of Recognition
The Berkeley Timesharing system for the SDS-940 had an earlier form of recognition. It didn't use escape however. On that system, recognition was automatic; whenever the user had typed enough to unambigiously identify a command or symbolic name, the system would spring to life and type the rest of it. This made for the minimum keystrokes in the ideal case, but had one major, and ultimately fatal, problem: if the user typed too much in one field, i.e. more than the amount necessary for the system to recognize that field, the input would go into the next field where it wasn't intended. For example, the system would recognize COP as sufficient for COPY and supply the "Y". But if you typed the whole verb, you would get:
* COPY Y
|
|- typed by the computer
Then, you would at least have to erase the extra "Y". If you didn't notice what happened and continued to type the remainder of the command, what you had intended as:
* COPY OLDFIL NEWFIL
would come out as
* COPY Y OLDFIL NEWFIL
This would at least produce an error, and in pathological cases could do major damage. [In the foregoing example, note that the old file name winds up in the new file parameter field.]
