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
signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
