[mr] bash-completion rules

[Joey Hess]

Adam Spiers wrote:
> there is a bigger cost - the risk of having a version of the completion
> rules which does not match the version of mr installed.

This is, in practice, not a large problem, and can be dealt with by
distribution integrators.

> There's also a converse argument.  Completion functions are not only
> coupled to the thing they are completing for, but also to the shell's
> completion API.  When the API changes, it's better to have completion
> functions within the shell's distribution, because the shell's
> developers can fix all completion functions to work with the new API
> in one go.

Which is why I would certianly not like to bundle zsh completion
functions with the programs they complete. You have to be a zsh guru to
write them, they have changed a *lot* over the years (I don't recognize
anything in the current dpkg completion that's left from the one I
originally wrote), and upstream is very responsive, to keep the completions
up-to-date.

I suspect that bash completion will head in a similar direction, as they
get reworked to support dynamically loading completions on demand, per
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/3375

With that said, putting a bash completion in mr now just means a little
probable pain later on, so I'm not strongly opposed. 

The real difficulty in completing mr is that it accepts an arbitrary set
of subcommands, even depending on what repository it's run in. In
practice, I just type abbreviated things like "mr up" and "mr p"
instead of reaching for the tab key; happily mr will accept any
nonambiguous abbreviations and can be taught others. :)

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111226/687d7449/attachment.pgp>