Re: [mr] bash-completion rules
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
Re: [mr] bash-completion rules
On Sat, Dec 17, 2011 at 2:14 PM, Antonio Ospite wrote: > On Sat, 17 Dec 2011 11:58:18 + > Adam Spiers 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 vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: [mr] bash-completion rules
On Sat, 17 Dec 2011 11:58:18 + Adam Spiers wrote: > On Sat, Dec 17, 2011 at 11:20 AM, Antonio Ospite > wrote: > > On Wed, 7 Dec 2011 17:11:52 +0100 > > Richard Hartmann wrote: > > [...] > >> > >> For zsh, it's > >> > >> /usr/share/zsh/functions/Completion/Unix/_mr > >> > >> but just send it to zsh-work...@zsh.org once done. > > > > That's a good point, maybe I too will just send the bash rules to the > > bash-completion project instead of having them in 'mr'. > > Personally I always thought that was the wrong approach, because > completion rules are necessarily coupled to functionality, e.g. if mr > learns a new option `--foo' then the completion rules need to learn it > at the same time. Therefore it makes sense for the completion rules > to live in the same repository as the program, and to be installed at > the same time the program is installed. > I obviously agree on that, in theory :) That's why I asked here first. > 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. > 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. > > 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, I am willing to update mr bash completion rules when needed, but I definitely don't want to communicate those changes twice, it's a waste of time. 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. Joey? Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpD6yuPtiZq8.pgp Description: PGP signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: [mr] bash-completion rules
On Sat, Dec 17, 2011 at 11:20 AM, Antonio Ospite wrote: > On Wed, 7 Dec 2011 17:11:52 +0100 > Richard Hartmann wrote: > >> On Wed, Dec 7, 2011 at 16:21, Adam Spiers wrote: >> >> > On Wed, Dec 7, 2011 at 2:34 PM, Antonio Ospite >> > wrote: >> >> >> or where else? >> > >> > Good question - I will probably write zsh completion rules for mr >> > at some point too. >> >> For zsh, it's >> >> /usr/share/zsh/functions/Completion/Unix/_mr >> >> but just send it to zsh-work...@zsh.org once done. > > That's a good point, maybe I too will just send the bash rules to the > bash-completion project instead of having them in 'mr'. Personally I always thought that was the wrong approach, because completion rules are necessarily coupled to functionality, e.g. if mr learns a new option `--foo' then the completion rules need to learn it at the same time. Therefore it makes sense for the completion rules to live in the same repository as the program, and to be installed at the same time the program is installed. 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. 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. So my recommendation would be: ship completion rules with mr, but also submit them to the shell project. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: [mr] bash-completion rules
On Wed, 7 Dec 2011 17:11:52 +0100 Richard Hartmann wrote: > On Wed, Dec 7, 2011 at 16:21, Adam Spiers wrote: > > > On Wed, Dec 7, 2011 at 2:34 PM, Antonio Ospite > > wrote: > > >> or where else? > > > > Good question - I will probably write zsh completion rules for mr > > at some point too. > > For zsh, it's > > /usr/share/zsh/functions/Completion/Unix/_mr > > but just send it to zsh-work...@zsh.org once done. > That's a good point, maybe I too will just send the bash rules to the bash-completion project instead of having them in 'mr'. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpeArU62aNTL.pgp Description: PGP signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: [mr] bash-completion rules
On Wed, Dec 7, 2011 at 16:21, Adam Spiers wrote: > On Wed, Dec 7, 2011 at 2:34 PM, Antonio Ospite > wrote: >> or where else? > > Good question - I will probably write zsh completion rules for mr > at some point too. For zsh, it's /usr/share/zsh/functions/Completion/Unix/_mr but just send it to zsh-work...@zsh.org once done. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: [mr] bash-completion rules
On Wed, Dec 7, 2011 at 2:34 PM, Antonio Ospite wrote: > Hi, > > I wrote bash-completion rules for mr, I will send a patch if you are > interested but before that I wanted to ask where you like the file to > be placed: > > ./mr-completion.bash > ./contrib/mr-completion.bash > ./completion/mr-completion.bash > > or where else? Good question - I will probably write zsh completion rules for mr at some point too. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
[mr] bash-completion rules
Hi, I wrote bash-completion rules for mr, I will send a patch if you are interested but before that I wanted to ask where you like the file to be placed: ./mr-completion.bash ./contrib/mr-completion.bash ./completion/mr-completion.bash or where else? Just out of curiosity: is it intentional that the man page does not mention the 'help' command in the commands list on the top? I see it is mentioned in the commands descriptions, tho. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpebOwWmvBt1.pgp Description: PGP signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
