On Sat, Jul 12, 2008 at 01:29:27PM +0000, Clint Adams wrote: >> It would be a good idea if individual maintainers could extend >> zsh's completion by just dropping a snippet in some directory >> analogous to bash's /etc/bash_completion.d.
I shouldn't have said "a good idea". It's certainly an idea, but I don't know if it's a good one. I don't mind if you tag this wontfix, really I don't. I'd just like to discuss exactly why it's a good/bad idea, so that next time someone has the idea they can find this ticket and not have to bother anyone about it (particularly, you or upstream). Maybe there's already such a ticket upstream, and I didn't find it. If that's the case, this ticket can just be linked to it (i.e. with the "forwarded" directive.) > What benefits does a completion.d directory offer? The "benefit" I see is that the responsibility of maintaining the completion code for a utility becomes the responsibility of the maintainer of that utility, rather than the zsh maintainers. I'm not sure if this is actually a benefit; it means the completion code will be written by people who are less fluent in zsh, but more aware of what the completion behaviour for the utility is. > One benefit to doing it centrally is that any API changes can be > fixed with a single changeset. Similarly, the proposed mechanism would allow the zsh completion file to be updated by the same changeset that introduces CLI changes. It would also mean that when there's a CLI-incompatible upgrade from foo_1 to foo_2 in Debian, it's not necessary to upgrade zsh to "fix" the completion script. I'm not really familiar with zsh, and I don't know how complex zsh completion code can be, or how often a CLI change would require changes to the associate completion code. (For example, add a new switch foo --bar is auto-detect by typical completion scripts because they get the list of available switches from foo --help.) It also occurs to me that perhaps the mechanism would allow versioned scripts, so that zsh version N can ship with completion support for foo M, but the foo maintainer can override that completion file with a different one in the foo M+1 package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
