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
Description: Digital signature
_______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home