On Thu, Jun 18, 2009 at 10:34 AM, Guillaume Rousse<guillaume.rou...@inria.fr> wrote: > And I favor the splitted solution because: > - calling directly the function with the proper behaviour is faster than > having this function test its argument at runtime to select which behavior > to use > - distinguishing between completion functions (those directly attached to a > command) and helper functions (those called by completion functions) make > the code easier to maintain
Right now the differences are that _known_hosts: - clears COMPREPLY (_known_hosts_real does not) - determines cur=`get_cword` (_known_hosts_real does not) I think I'm in favour of the splitted solution as well (especially because of the unnecessary calls to `get_cword'), although I'd prefer another name instead of `..real'. Maybe we can call these helper functions `add...', e.g. `_add_known_hosts', since they *add* to COMPREPLY where the directly called functions *set* COMPREPLY. More suggestions? Should we rename all helper functions, e.g. _filedir > _filedir_real (or _add_filedir), _services > _services_real (or _add_services), etc.? Or is this something to defer till after we branched off bash-2 support? Another issue regarding function names, maybe also better to do till after we dropped bash-2 support, is namespaces. We're using quite common function names and I can image bash completion functions clashing with user defined functions, e.g. _cd(). Shouldn't we prefix all functions with _bc_ or _comp or ? (suggestions?) to simulate some kind of namespace in which we avoid function name conflicts out there? > - bash isn't wise enough to to distinguish between an empty string argument > and an non-existing one: calling the '_known_host -a' function with no > current host will call '_known_host_real -h "" -a', and result in completion > for hosts called -a* I'm not sure if this is really the problem or if this happened because getopts encountered an empty string in the middle of the options (see previous reply)? Turning the -h option into a mandatory argument is fine with me too, I think I don't really understand your point, but feel free to change. I see e.g. _filedir and _services are also relying on a global `cur' :-( I think it would be better for all helper functions not to rely on globals and pass `cur' to them as an option/argument? But maybe this is not the right time/branch to change it all. Maybe we should try to get more consensus about what everybody think is desired. We can also restore the `ocur' backup variable to `_known_hosts_real' so at least all helper functions are working the same, i.e. relying on global `cur'. Greetings, Freddy _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel