* custom script Bash completion @ 2013-11-10 16:14 Thomas Ballinger 2013-11-10 18:24 ` Bart Schaefer 0 siblings, 1 reply; 7+ messages in thread From: Thomas Ballinger @ 2013-11-10 16:14 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 424 bytes --] I'd like to use bash completion in zsh for a script with complete -C 'tu --get-bash-completion' tu 'tu --get-bash-completion' is invoked by zsh completion, but the three arguments bash would pass to it aren't being passed. Is there another config option I need to know about, or is this behavior not implemented? Question also here: http://stackoverflow.com/questions/19662649/using-bash-complete-c-in-zsh Thanks, Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 16:14 custom script Bash completion Thomas Ballinger @ 2013-11-10 18:24 ` Bart Schaefer 2013-11-10 19:09 ` Thomas Ballinger 2013-11-10 23:18 ` Chet Ramey 0 siblings, 2 replies; 7+ messages in thread From: Bart Schaefer @ 2013-11-10 18:24 UTC (permalink / raw) To: zsh-users On Nov 10, 11:14am, Thomas Ballinger wrote: > > I'd like to use bash completion in zsh for a script with > > complete -C 'tu --get-bash-completion' tu > > 'tu --get-bash-completion' is invoked by zsh completion, but the three > arguments bash would pass to it aren't being passed. I'm not absolutely sure if the following explains that, because none of the bash man pages I can find describe what those three arguments are, but: The zsh bash completions are compatible with bash 2.05b and it is possible that those three arguments were not passed by that version. Volunteers to update Completion/bashcompinit? > Is there another config option I need to know about, or is this behavior > not implemented? Based on a quick peek at "compgen" in bashcompinit and a couple of stabs with "complete -C /bin/echo foo" in bash itself, Thomas is expecting the external command defined with "complete -C" to receive the same three arguments that are passed to a shell function with "complete -F". So the workaround for this particular anomaly is to do tu_completer() { echo $(tu --get-bash-completion "$@") } complete -F tu_completer tu ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 18:24 ` Bart Schaefer @ 2013-11-10 19:09 ` Thomas Ballinger 2013-11-10 20:25 ` Bart Schaefer 2013-11-10 23:18 ` Chet Ramey 1 sibling, 1 reply; 7+ messages in thread From: Thomas Ballinger @ 2013-11-10 19:09 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users [-- Attachment #1: Type: text/plain, Size: 2243 bytes --] Thanks very much Bart, I'm now using tu_completer(){ IFS=$'\n' # in loop below, iterate over lines, not words for name in $(tu --get-bash-completion "$@"); do echo $name done } because some of the suggestions contained spaces, and functionality is improved. However, completion suggestions are still filtered though by "values that the user has typed the first letters of," preventing the fuzzy completion I'd written from taking effect: tu comment jorge<tab> should result in tu comment George Washington or tu comment jorge George Washington Fred Jorrge Elizabeth George if there are multiple options, but they don't - no suggestions show up. (apparently because none of the suggestions returned by my completion script/function start with "jorge") tu comment Geo<tab> works fine. I imagine I need to turn off some zsh completion feature for this completion? Tom On Sun, Nov 10, 2013 at 1:24 PM, Bart Schaefer <schaefer@brasslantern.com>wrote: > On Nov 10, 11:14am, Thomas Ballinger wrote: > > > > I'd like to use bash completion in zsh for a script with > > > > complete -C 'tu --get-bash-completion' tu > > > > 'tu --get-bash-completion' is invoked by zsh completion, but the three > > arguments bash would pass to it aren't being passed. > > I'm not absolutely sure if the following explains that, because none of > the bash man pages I can find describe what those three arguments are, > but: The zsh bash completions are compatible with bash 2.05b and it is > possible that those three arguments were not passed by that version. > > Volunteers to update Completion/bashcompinit? > > > Is there another config option I need to know about, or is this behavior > > not implemented? > > Based on a quick peek at "compgen" in bashcompinit and a couple of stabs > with "complete -C /bin/echo foo" in bash itself, Thomas is expecting the > external command defined with "complete -C" to receive the same three > arguments that are passed to a shell function with "complete -F". > > So the workaround for this particular anomaly is to do > > tu_completer() { > echo $(tu --get-bash-completion "$@") > } > complete -F tu_completer tu > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 19:09 ` Thomas Ballinger @ 2013-11-10 20:25 ` Bart Schaefer 2013-11-10 21:34 ` Thomas Ballinger 0 siblings, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2013-11-10 20:25 UTC (permalink / raw) To: zsh-users On Nov 10, 2:09pm, Thomas Ballinger wrote: } } [...] completion suggestions are still filtered though by "values } that the user has typed the first letters of," preventing the fuzzy } completion I'd written from taking effect: Zsh completion assumes that the completion function is going to produce all possible words that could appear at that position on the command line; the internals then perform the filtering to match against the partial word that is already present if any. It was our feeling at the time that it was far too much to expect every completion function author to consider details such as whether the cursor was in the middle of the word, etc. The "compadd -U" option was created to enable authors to have that degree of control, but it's not the default and it's not used in the emulation functions defined by bashcompinit. } I imagine I need to turn off some zsh completion feature for } this completion? I think you're going to have to replace bashcompinit with a slightly edited version. Perhaps if we get a volunteer to update bashcompinit, that person can figure out how to make this optional. In any case, according to comments in bashcompinit the diff below might be what you need. I threw in making "complete -C" pass the same args as "complete -F". diff --git a/Completion/bashcompinit b/Completion/bashcompinit index 902fa88..e2b3597 100644 --- a/Completion/bashcompinit +++ b/Completion/bashcompinit @@ -26,7 +26,7 @@ _bash_complete() { compset -S '/*' && matches=( ${matches%%/*} ) compadd -Q -f "${suf[@]}" -a matches && ret=0 else - compadd -Q "${suf[@]}" -a matches && ret=0 + compadd -U -Q "${suf[@]}" -a matches && ret=0 fi fi @@ -137,7 +137,10 @@ compgen() { unsetopt nullglob ;; W) results+=( ${(Q)~=OPTARG} ) ;; - C) results+=( $(eval $OPTARG) ) ;; + C) + local -a args + args=( "${words[0]}" "${@[-1]}" "${words[CURRENT-2]}" ) + results+=( $(eval $OPTARG "${args[@]}") ) ;; P) prefix="$OPTARG" ;; S) suffix="$OPTARG" ;; X) @@ -152,7 +155,7 @@ compgen() { # support for the last, `word' option to compgen. Zsh's matching does a # better job but if you need to, comment this in and use compadd -U - # (( $# >= OPTIND)) && results=( "${(M)results[@]:#${@[-1]}*}" ) + (( $# >= OPTIND)) && results=( "${(M)results[@]:#${@[-1]}*}" ) print -l -r -- "$prefix${^results[@]}$suffix" } -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 20:25 ` Bart Schaefer @ 2013-11-10 21:34 ` Thomas Ballinger 0 siblings, 0 replies; 7+ messages in thread From: Thomas Ballinger @ 2013-11-10 21:34 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users [-- Attachment #1: Type: text/plain, Size: 2890 bytes --] Thanks very much Bart. I regret I can't be this volunteer at this time, but best of luck if anyone takes it on. One of these days I'll learn to write a real zsh completion script and use that instead :) Tom On Sun, Nov 10, 2013 at 3:25 PM, Bart Schaefer <schaefer@brasslantern.com>wrote: > On Nov 10, 2:09pm, Thomas Ballinger wrote: > } > } [...] completion suggestions are still filtered though by "values > } that the user has typed the first letters of," preventing the fuzzy > } completion I'd written from taking effect: > > Zsh completion assumes that the completion function is going to produce > all possible words that could appear at that position on the command > line; the internals then perform the filtering to match against the > partial word that is already present if any. It was our feeling at the > time that it was far too much to expect every completion function author > to consider details such as whether the cursor was in the middle of the > word, etc. The "compadd -U" option was created to enable authors to > have that degree of control, but it's not the default and it's not used > in the emulation functions defined by bashcompinit. > > } I imagine I need to turn off some zsh completion feature for > } this completion? > > I think you're going to have to replace bashcompinit with a slightly > edited version. Perhaps if we get a volunteer to update bashcompinit, > that person can figure out how to make this optional. In any case, > according to comments in bashcompinit the diff below might be what you > need. > > I threw in making "complete -C" pass the same args as "complete -F". > > diff --git a/Completion/bashcompinit b/Completion/bashcompinit > index 902fa88..e2b3597 100644 > --- a/Completion/bashcompinit > +++ b/Completion/bashcompinit > @@ -26,7 +26,7 @@ _bash_complete() { > compset -S '/*' && matches=( ${matches%%/*} ) > compadd -Q -f "${suf[@]}" -a matches && ret=0 > else > - compadd -Q "${suf[@]}" -a matches && ret=0 > + compadd -U -Q "${suf[@]}" -a matches && ret=0 > fi > fi > > @@ -137,7 +137,10 @@ compgen() { > unsetopt nullglob > ;; > W) results+=( ${(Q)~=OPTARG} ) ;; > - C) results+=( $(eval $OPTARG) ) ;; > + C) > + local -a args > + args=( "${words[0]}" "${@[-1]}" "${words[CURRENT-2]}" ) > + results+=( $(eval $OPTARG "${args[@]}") ) ;; > P) prefix="$OPTARG" ;; > S) suffix="$OPTARG" ;; > X) > @@ -152,7 +155,7 @@ compgen() { > > # support for the last, `word' option to compgen. Zsh's matching does a > # better job but if you need to, comment this in and use compadd -U > - # (( $# >= OPTIND)) && results=( "${(M)results[@]:#${@[-1]}*}" ) > + (( $# >= OPTIND)) && results=( "${(M)results[@]:#${@[-1]}*}" ) > > print -l -r -- "$prefix${^results[@]}$suffix" > } > > -- > Barton E. Schaefer > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 18:24 ` Bart Schaefer 2013-11-10 19:09 ` Thomas Ballinger @ 2013-11-10 23:18 ` Chet Ramey 2013-11-11 2:12 ` Bart Schaefer 1 sibling, 1 reply; 7+ messages in thread From: Chet Ramey @ 2013-11-10 23:18 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users, chet.ramey On 11/10/13, 1:24 PM, Bart Schaefer wrote: >> 'tu --get-bash-completion' is invoked by zsh completion, but the three >> arguments bash would pass to it aren't being passed. > > I'm not absolutely sure if the following explains that, because none of > the bash man pages I can find describe what those three arguments are, In the Bash-4.2 info manual, you find: "After these matches have been generated, any shell function or command specified with the @option{-F} and @option{-C} options is invoked. When the command or function is invoked, the @env{COMP_LINE}, @env{COMP_POINT}, @env{COMP_KEY}, and @env{COMP_TYPE} variables are assigned values as described above (@pxref{Bash Variables}). If a shell function is being invoked, the @env{COMP_WORDS} and @env{COMP_CWORD} variables are also set. When the function or command is invoked, the first argument is the name of the command whose arguments are being completed, the second argument is the word being completed, and the third argument is the word preceding the word being completed on the current command line." Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: custom script Bash completion 2013-11-10 23:18 ` Chet Ramey @ 2013-11-11 2:12 ` Bart Schaefer 0 siblings, 0 replies; 7+ messages in thread From: Bart Schaefer @ 2013-11-11 2:12 UTC (permalink / raw) To: zsh-users On Nov 10, 6:18pm, Chet Ramey wrote: } } In the Bash-4.2 info manual, you find: Thanks, Chet. I searched for mentions of the "complete" builtin but didn't dig far enough into the paragraphs describing what was done to process a "compspec". Among other likely deficiencies, it looks like the "complete" emulator defined by bashcompinit does not support the -E (empty command name) or -D (default) options (which may very well be intentional, but there's really no documentation for bashcompinit); and it probably is not processing the steps in the right order (e.g., commands with -C may be handled before functions with -F, and wordlist with -W might come after both where the bash manual says they should come first, etc.). So this could use an overhaul if anyone feels so inclined. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-11-11 2:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-10 16:14 custom script Bash completion Thomas Ballinger 2013-11-10 18:24 ` Bart Schaefer 2013-11-10 19:09 ` Thomas Ballinger 2013-11-10 20:25 ` Bart Schaefer 2013-11-10 21:34 ` Thomas Ballinger 2013-11-10 23:18 ` Chet Ramey 2013-11-11 2:12 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).