David Paleino <d.paleino <at> gmail.com> writes: > Well. > To start hacking on the fork, I'm going to create a separate bzr branch. > Reading http://fvue.nl/wiki/Bash_completion_library , it seems pretty smart > (really, loading completions only when needed is smarter than loading > everything just using have()) > > I also really like the DejaGNU test suites -- we haven't anything like that in > the old code, and would really need it.
Merging Debian-completion with bash-completion-lib is possible (and I'm in favor). Here're already a few things to consider: 1. Completions reside in a somewhat arcane directory-structure: $ ls -1 completions complete complete-ant complete-cc complete-cd complete-linux complete-nohostcomplete complete -o default complete -o default -o filenames complete -o default -o nospace complete -o dirnames complete -o filenames complete -o filenames -o nospace complete -o nospace complete-restrict-by-extension complete-tar For reasons see: http://www.fvue.nl/wiki/Bash_completion_library#Problem_2:_Completion_can.27t_access_completion_meta-options It looks like this arcane directory structure can be overthrown as soon as bash-4 which has a `compopt' builtin, but this is not helping bash-3 right now. 2. Completion-*implementations* are only loaded when needed, but completion-*definitions* are still installed for *all* commands (although being the single small function `comp_load'): $ complete -p complete -o filenames -F comp_load reportbug complete -o filenames -F comp_load split complete -o filenames -F comp_load sed complete -o filenames -F comp_load ld complete -o filenames -F comp_load grep complete -o filenames -F comp_load java complete -o default -F comp_load _longopt-default complete -o default -F comp_load dict complete -F comp_load withlist ... (etc.) For reasons see: http://www.fvue.nl/wiki/Bash_completion_library#Problem_1:_No_.60catch-all.27_complete It looks like Fedora has already patched bash with a catch-all completion handler, which could in theory be set to "comp_load", but it also looks like the catch-all handler is not going to be in upstream bash < 4.1 ... 3. Completions reside in `completions' subdirectories of `$COMP_PATH' (a colon-separated list of directories) 4. Helper functions reside in a subdirectory `include'. Helper functions can be loaded by calling `comp_include', e.g. ./completions/complete-nohostcomplete/ssh does: comp_include _dequote _known_hosts If merging proves difficult, maybe we can start with sharing the DejaGNU test suite. The test suite is already split into two parts: loading and completing, and I'm already using the test suite for completions of both Debian-completion and bash-completion-lib. I think the best solution would be to extract the test suite from bash-completion-lib and make it a separate project? But maybe I'm jumping to a conclusion too fast. If completion-lib merges with Debian-completion maybe there's no need to keep a separate test suite. Did I already say I was in favor of merging and make completion loading 5-10 times faster(!) Freddy Vulto http://fvue.nl/wiki/Bash_completion_library _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel