Re: a different approach to autocompletion

[Eric Blake]

According to Martin Walch on 3/3/2010 3:03 PM:
> 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.

No, most shells do pure filename completion only as a default fallback if
you have not defined a more powerful programmable completion.

> 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.

Unless you use a library of shell completions designed for each particular
program.  For bash, see
 http://bash-completion.alioth.debian.org/
I know that zsh also has decent libraries built, but as I don't use zsh, I
can't easily point you to a link.

> 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.

Thanks for the suggestion.  However, I'm personally opposed to doing this
in-program.  It will make EVERY program larger, in order to add the
completion bits.  The UNIX philosophy is to do particular tasks well, and
the shell already does _programmable_ completion well.  I think the time
is better spent enhancing the programmable completion libraries associated
with each shell.

That said, it _does_ make sense for individual packages to contribute to
the programmable completion libraries.  For example, the bash-completion
project does not supply any completions for git.  Why?  Because git
supplies its own library of completions which can be hooked into the
bash-completion framework.  The question then becomes which packages are
so complex and frequently changing that the work of programmable
completion is better delegated to the package rather than to the
programmable completion library.  Coreutils probably falls in the latter
(it is stable and the interfaces change slowly enough that the
bash-completion project has no problem keeping up with changes in
coreutils' interfaces).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature