Re: [Bash-completion-devel] using external helpers for completion
On Sunday 07 November 2010, Guillaume Rousse wrote: Le 31/10/2010 23:59, Freddy Vulto a écrit : The remaining error reported by the test suite however, was that perldoc option-completion is now missing; it's not in the pure perl perldoc completion helper, whereas the code underneath was in the bash perldoc completion: -if [[ $cur == -* ]]; then -COMPREPLY=( $( compgen -W '-C -s -T -u -U -W -X -h -v -V -c -w -d \ --D -p -n -a -F -l -0 -I -m -M -P -S -x -i -e ' -- $cur ) ) Are you aware of that? Anyway, I removed the test case from the test suite for now. Good catch, I didn't notice. I just fixed this, Shouldn't the perldoc test case be re-enabled now then? and also generalized the helper to be used for perl command also. Now we have 100% pure perl completions for those commands, allowing to get rid of ugly perl oneliners embedded in shell functions for listing perl modules. However, we also have to reimplement compgen -d, and filedirs, with no garanty of providing a consistent behaviour :/ I wonder if the correct solution would be to keep a shell completion functions, and only delegate the specialized parts (modules and function completions) to external perl code. Sounds like a plan to me (offhand). BTW after this change we now have the perl testcase in a fairly bad shape. $ ./runCompletion perl.exp [...] # of expected passes3 # of unexpected failures2 # of unresolved testcases 3 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
Le 07/11/2010 10:03, Ville Skyttä a écrit : On Sunday 07 November 2010, Guillaume Rousse wrote: Le 31/10/2010 23:59, Freddy Vulto a écrit : The remaining error reported by the test suite however, was that perldoc option-completion is now missing; it's not in the pure perl perldoc completion helper, whereas the code underneath was in the bash perldoc completion: -if [[ $cur == -* ]]; then -COMPREPLY=( $( compgen -W '-C -s -T -u -U -W -X -h -v -V -c -w -d \ --D -p -n -a -F -l -0 -I -m -M -P -S -x -i -e ' -- $cur ) ) Are you aware of that? Anyway, I removed the test case from the test suite for now. Good catch, I didn't notice. I just fixed this, Shouldn't the perldoc test case be re-enabled now then? I attempted to do it, but the test suite is still quite mysterious for me. I reverted commit 325b1c2, and added a test similar to the one for perl. and also generalized the helper to be used for perl command also. Now we have 100% pure perl completions for those commands, allowing to get rid of ugly perl oneliners embedded in shell functions for listing perl modules. However, we also have to reimplement compgen -d, and filedirs, with no garanty of providing a consistent behaviour :/ I wonder if the correct solution would be to keep a shell completion functions, and only delegate the specialized parts (modules and function completions) to external perl code. Sounds like a plan to me (offhand). BTW after this change we now have the perl testcase in a fairly bad shape. $ ./runCompletion perl.exp [...] # of expected passes3 # of unexpected failures2 # of unresolved testcases 3 I fixed it, by implementing the proposed scheme. Basically, I replaced the helper modules completion code by our oneliner, while fixing some issues with it. The original code has a nice trick: instead of returning all perl modules matching the current word, it just complete on current namespace segment: X - XML:: XMLRPC:: XPath XSLoader The result is quicker, and also easier to handle for the user. However, it also relies on using -o nospace option to be able to continue completion directly, rather than using backspace first. Also, we face the painful 'every : character start a new completion' issue again :( -- BOFH excuse #381: Robotic tape changer mistook operator's tie for a backup tape. smime.p7s Description: S/MIME Cryptographic Signature ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 101101 09:10, Ville Skyttä wrote: I suppose something like SUBDIRS = helpers in completions/Makefile.am would fix installing the helper (untested). Yes, that seems to fix it. I've added strengthen use of GNU Autotools (add to README, fix `make distcheck`) to the roadmap as an objective for version 2.0. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 100828 18:32, Guillaume Rousse wrote: However, I'd like us to decide on a final setup, that would be: 1) FHS-compliant 2) efficient in term of time spent to source files at each new bash process start (that's the initial goal of distinguishing between installation and activation directory) 3) enforced by our installation process (we currently hardcode /etc/bash_completion.d in bash_completion file, instead of relying on installation process to set it according to --sysconfdir variable) 4) avoid conveniancy symlinks, as the one we're just discussing here That is supposed to be a 2.0 release objective, after all. Yes, it would be nice if could tackle this and now incorporate any `helpers' directory in it. What if we would create an environment variable `BASHCOMP_PATH' (prefix is going to be `bashcomp_' isn't it?), containing colon-separated (:) directories. Each of these directories should contain mandatory directories, being: - completions (the renamed `contrib') - helpers BASHCOMP_PATH typically would contain these directories: /usr/share/bash-completion /etc/bash_completion.d/ ~/bash_completion.d but allows for each distribution to vary. I'm not sure how we would incorporate per-user config settings. Maybe bash_completion could look in each of the BASHCOMP_PATH directories for a `bash_completion' or `.bashcomprc' file? If we would first agree on BASHCOMP_PATH, we could then second decide on how BASHCOMP_PATH should be set up by an installer. Thoughts? I'm hesitating to add yet another configuration variable, especially since contrib helpers are so tied together (we would also need a BASH_COMPLETION_COMPAT_DIR_HELPER, ugh). I still don't know what's this variable is for, BTW. I was thinking if BASH_COMPLETION_DIR/contrib gets a `helpers' dir with a variable pointing to it, then BASH_COMPLETION_COMPAT_DIR/contrib would need one as well. So, I'm absolutly OK for another symlink as a temporary solution, but I'd prefer to achieve our long-time objective as well. And if testing has specific issues, I'd prefer them to be solved by test-time only solutions/hacks/whatever than permanent setup ones. Let's add the symlink then until we decide on a final setup. I'm fine with adjusting the test suite, but I also expect people - just like me - running bash_completion directly from git HEAD without doing a `make', and I think it would be better if we can defer `make' substitutions to the install phase so that the bash_completion source stays simpler. Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
Le 27/08/2010 21:46, Ville Skyttä a écrit : On Friday 27 August 2010, Freddy Vulto wrote: I'm hesitating to add yet another configuration variable, especially since contrib helpers are so tied together (we would also need a BASH_COMPLETION_COMPAT_DIR_HELPER, ugh). BTW if someone cares, contrib is no longer a too descriptive name for the stuff in it... I do. I'd suggest 'completions', by opposition to 'helpers'. -- BOFH excuse #444: overflow error in /dev/null smime.p7s Description: S/MIME Cryptographic Signature ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 100825 22:58, Guillaume Rousse wrote:
That's a good idea, that would avoid install-time substitution.
However, $BASH_COMPLETION_DIR point to the directory where completions
are sourced, whereas many of us (fedora and mandriva maintainers) only
put symlinks there, and use a distinct directory for installing the
whole set of available completions.
Then you can also create a `helpers' symlink there?
So, I'd rather use a distinct BASH_COMPLETION_DIR_HELPER for this, and
provide it a default value (/usr/share/bash-completion/helper) in main
bash_completion file.
I'm hesitating to add yet another configuration variable, especially
since contrib helpers are so tied together (we would also need a
BASH_COMPLETION_COMPAT_DIR_HELPER, ugh).
complete -C ${BASH_SOURCE[0]%/*}/helpers/perldoc perldoc
Installation setup doesn't mandatorily match archive setup.
But we could make it mandatory for BASH_COMPLETION_DIR to have a
(symlinked) `helpers' subdir? More enforcements are coming if we're
going to merge bash-completion-lib...
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On Fri, 27 Aug 2010 09:08:29 +0200, Freddy Vulto wrote: But we could make it mandatory for BASH_COMPLETION_DIR to have a (symlinked) `helpers' subdir? More enforcements are coming if we're going to merge bash-completion-lib... *We* are upstream, *we* decide. Enforcing things is one of our prerogatives :) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
