On Saturday 17 January 2009, you wrote: > El sáb, 17-01-2009 a las 02:47 +0200, Ville Skyttä escribió: > > On Saturday 17 January 2009, Santiago M. Mola wrote:
> David changed gzip completion to parse gzip --help, so it's fixed now. Good stuff. The implementation does seem to overlap the functionality of _longopt a bit though (or the other way around), but that's more or less cosmetic. Note about what follows: I'm not trying to be an ass or to force feed my opinions, but new here (but not new to bash-completion), rather trying to develop a gut feeling what people think bash-completion should or should not do. > > distros I have access to or otherwise looked at their sources (Fedora, > > CentOS, openSUSE, Mandriva, Debian; all of these had --rsyncable). > > That's still a tiny subset of available distros, Not really if you take into account the derivatives of those (which I assume do also carry that patch). But yep, then there's all the non-Linux environments where bash-completion is supposed to work as well. > which is quite opposite to "practical portability". I disagree. > Gentoo, for example, hasn't --rsyncable option. We'll always find some setups that do not have everything we expect, and we have to make assumptions. Nobody can test every setup available out there, and judgement calls have to be made. And we're all more or less biased - if Gentoo had --rsyncable, would you have objected to this addition? > I hope in the future we take the most generic approach (when possible), > specially when talking about distro-specific options. If the vast majority of target environments has something and a handful does not (patched in or not, and not specifically referring to gzip --rsyncable here), which one of these is the exception that we should leave to users or package maintainers of those environments? > That is, the lowest common denominator policy Personally, I certainly hope this is not going to happen. > or automatic guessing. If by this you mean things like parsing the available options dynamically from somewhere, it is clearly a winner when it can be done robustly. > On some projects, bash-completion modules are shipped with upstream > tarballs and maintained there, This is good (as long as they're really maintained in addition to being included)... > so people always have the correct version installed. ...but one problem is that a lot of upstream projects that ship completions do not actually install them, users or package maintainers need to take care of that. I suppose better filesystem layout for bash-completion and documentation about it could change this. Ditto mentioning what is the stable API (various helper functions etc) of bash-completion that external module writers can rely on being available. These would probably have a positive effect on more upstreams' willingness to include completion modules in their source trees and deliverables in the first place, not only the "include but do not install" part. _______________________________________________ Bash-completion-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
