zsh-users
 help / color / mirror / code / Atom feed
* 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).