a different approach to autocompletion

[Martin Walch]

Hello list,

sorry if this is not the appropriate place for the following suggestion, but I 
do not which place would be bette.

I think autocompletion in shells (that is usually triggered with tab) is a 
great feature which I do not want to miss. However, over the years, I have 
seen several autocomplete implementations from a user's point of view and I 
think the whole mechanism is a mess. Many shells are trying to guess proper 
program names and command line arguments for every single program. The 
autocompletion for program names is working well in most cases. But the 
completion of command line arguments is broken by design. Why are shells even 
trying to guess command line arguments? They can not know for every program in 
the world what arguments it will take.

They still try to do it, because it is a useful feature. It it so useful, that 
I think it should be implemented in a proper way. However, in my opinion it is 
not up to a shell to decide what parameters and values may be passed to a 
command line program, as it can not know them all. Of course, it is possible 
to know what arguments a program from e. g. coreutils may take and to 
implement an autocompletion in the shell accordingly. However, this can only 
work with known programs, needs to be updated when the programs change, and 
needs to parse command line arguments similarly to how it is already done in 
the program itself.

Therefore I have an idea: let the program do the completion by itself. Every 
program could implement an interface that takes the already typed command line 
(and maybe pwd) and returns one or more suggestions for completion, or no 
suggestion or an error if there is no way to complete the argument. This could 
bring pretty many advantages:

- always in sync with the available commands in the current version of a 
program
- much mightier and more accurate, as e. g. make could autocomplete rules
- the scope is no more limited, as every program can implement this, the shell 
does need not to know it
- saves pretty much work, as there is no need to implement things more than 
once (no more in every shell)

I do not know how such an interface should be technically implemented. Maybe 
it can somehow be a part of the executable ELF file? Or maybe it should be a 
module that would be placed separately as a library? However, obviously, it 
would be useful to have a good, easy to use, standardized library (POSIX?) for 
defining, parsing and autocompleting command line arguments, probably with 
distinction between syntax and semantics, and with some standard 
implementations for autocompletion that may be overridden by the programmer if 
necessary.

Such an interface could be even more expanded for things like version number 
or quick help. Additionally to a tab completion, there could be another key or 
key combination for a quick help on the last parameter. This interface could 
even allow to get informations about website, authors, license and so on.

In further development of the whole GNU system, filesystems could save files 
together with their file types (instead of guessing it with the program file 
or even worse, by file extension), which would allow easy filtering by file 
types, making autocompletion (and many other things) even better.

This is the rough idea. Do you think this is a good idea? Is there any chance 
that this can be accomplished?

Regards
Martin Walch
-- 
free software for a free society