On Sat, Dec 17, 2011 at 2:14 PM, Antonio Ospite <osp...@studenti.unina.it> wrote: > On Sat, 17 Dec 2011 11:58:18 +0000 > Adam Spiers <vcs-h...@adamspiers.org> wrote: >> Unfortunately, in practice this isn't perfect, because (a) a program's >> upstream maintainer(s) and its completion rule maintainer(s) are often >> not the same people (e.g. the maintainer of program X may not ever use >> bash/zsh) and (b) there is no official standard on where an >> installation should drop a new completion function. > > The cost of (a) is, for example, that bash-completion rules are going to > be copied to the filesystem even if bash itself isn't installed at all. > FWIW I think I could live with some zsh-related files on my system even > if I don't use zsh.
Sure, that's a tiny cost, but as I think you already understand, 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 a common problem; for example on one of my machines, I have a very recent (developer) version of git which supports `git remote set-url' but an older version of zsh which does not know how to complete this. I could upgrade my zsh, but while this may provide something closer to the correct completion for git, it could make completion worse for many other commands on my system (e.g. by offering to complete newer options which are not yet available for the older versions of those commands which I have installed). 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. The tension between these diametrically opposed considerations reinforces my previous statement: >> Therefore in practice, it's up to the distribution packagers to get >> this right, but their job is made a lot easier if the upstream tarball >> contains the completion functions, and all they have to do is ensure >> that the rpm/deb/whatever places that file in the correct location, >> which ideally would override the completion function shipped with the >> shell. because the distribution packagers are the only people who can resolve these conflicts - after all, the whole point of a distro is to choose snapshots of versions of thousands of different packages and make sure they all work together nicely. It also reinforces my previous recommendation: >> So my recommendation would be: ship completion rules with mr, but also >> submit them to the shell project. > I'd really like to avoid duplication Normally I'd agree with you 100% (DRY!), but I think this is an exception, because having completion functions in both the shell codebases and mr's codebase encourages maintenance by both shell developers and mr developers. If mr learns a new option (e.g. the recent `--force') then the completion functions in the mr repository will too. If bash's completion API changes, the bash developers will update the mr completion function accordingly. Both types of change will eventually find their way to the opposite repository. > I am willing to update mr bash completion rules when needed But this would mean that every time someone else upgrades their mr installation, they may also have to upgrade bash, which is really bad. > but I definitely don't want to communicate > those changes twice, it's a waste of time. It's only a waste of time if every distribution out there correctly packaged the completion function(s) along with mr. Bundling a fall-back version with the shell means that even if the distribution package is missing the completion function(s), at least the user still gets some completion, even if it is not 100% correct. > I'd say it's up to the author of mr to decide whether he wants to keep > this stuff into his codebase or not. That's very true :-) _______________________________________________ vcs-home mailing list email@example.com http://lists.madduck.net/listinfo/vcs-home