context for globbing qualifiers based on command

context for globbing qualifiers based on command

[Martin Richter]

Hi there,

unfortunately I'm not too well familiar with the syntax of zstyle and
setting appropriate contexts to achieve the following (although there
were quite some nice examples on this list now and then).

Suppose there is a function foo which we can use as a globbing qualifier
a la
  print -l *(e:foo)
maybe even such that it takes an argument
  print -l *(e:foo 5)

Is it possible to tweak the completion such that shell functions are
grouped at the top when pressing TAB when using (:e...) on a given command?
  print -l *(e:TAB --> gives a lot of possible functions etc
but
  special_command *(e:TAB
gives only shell function matching some regexp or gives only the single
function 'foo' or members of an array of functions?

Thanks,
Martin

PS: Just in case it is not clear what I mean by the above, here the
example I need it for: special_command needs filenames as arguments in
which two numbers appear. I now want to use only those files in which
the numbers have a certain sum (one could also think of product or
whatsoever)

So there are shell functions (aka the above `foo')
  sum_equals
and
  product_equals
and I want
  special_command file_<->_<->.dat*(:TAB
to give only sum_equals and product_equals (or at least group them
together and show them at the top)

Re: context for globbing qualifiers based on command

[Bart Schaefer]

(It wasn't necessary to send this inquiry twice.  It sometimes takes a
little while for a response.)

On Feb 27, 11:20am, Martin Richter wrote:
>
> Is it possible to tweak the completion such that shell functions are
> grouped at the top when pressing TAB when using (:e...) on a given command?
>   print -l *(e:TAB --> gives a lot of possible functions etc
> but
>   special_command *(e:TAB
> gives only shell function matching some regexp or gives only the single
> function 'foo' or members of an array of functions?

Unfortunately, no.  The zstyle context after *(e: is identical to the
context in any other command position.

However, the $words array hasn't been altered, so you could write a
function to be installed in your "completer" style that examines the
values of $words[1] and $words[CURRENT], something like this:

_special_command_glob_completer() {
  if [[ CURRENT -gt 1 &&
        "$words[1]" = 'special_command' &&
        "$words[CURRENT]" = *\(*e:* ]]
  then
    compset -p ${#words[CURRENT]}
    compadd -J special-globbers sum_equals product_equals
    return 0
  else
    return 1
  fi
}

zstyle ':completion:*' completer _expand \
	_special_command_glob_completer \
	_complete _match _ignored _approximate _prefix

(the rest of that completer style is just for example, but you probably
want at least _complete in there after your special one).

It might also be possible to do this more generically with a "matcher"
zstyle in the context :completion::complete:-command-::* but I'll leave
that for someone else to work out.  (It'd have to use "zstyle -e" and
some kind of test similar to the "if" above.)

Re: context for globbing qualifiers based on command

[Martin Richter]

Hi,

> (It wasn't necessary to send this inquiry twice.  It sometimes takes a
> little while for a response.)
Oh, I'm very sorry! I had a look at
  http://www.zsh.org/mla/workers/2012/index.html
and couldn't find the post and therefore thought I messed up the sending
somehow. Please excuse me -- I didn't mean to be rude.

Martin

Re: context for globbing qualifiers based on command

[Mikael Magnusson]

On 29 February 2012 19:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
> (It wasn't necessary to send this inquiry twice.  It sometimes takes a
> little while for a response.)
>
> On Feb 27, 11:20am, Martin Richter wrote:
>>
>> Is it possible to tweak the completion such that shell functions are
>> grouped at the top when pressing TAB when using (:e...) on a given command?
>>   print -l *(e:TAB --> gives a lot of possible functions etc
>> but
>>   special_command *(e:TAB
>> gives only shell function matching some regexp or gives only the single
>> function 'foo' or members of an array of functions?
>
> Unfortunately, no.  The zstyle context after *(e: is identical to the
> context in any other command position.
>
> However, the $words array hasn't been altered, so you could write a
> function to be installed in your "completer" style that examines the
> values of $words[1] and $words[CURRENT], something like this:
>
> _special_command_glob_completer() {
>  if [[ CURRENT -gt 1 &&
>        "$words[1]" = 'special_command' &&
>        "$words[CURRENT]" = *\(*e:* ]]
>  then
>    compset -p ${#words[CURRENT]}
>    compadd -J special-globbers sum_equals product_equals
>    return 0
>  else
>    return 1
>  fi
> }
>
> zstyle ':completion:*' completer _expand \
>        _special_command_glob_completer \
>        _complete _match _ignored _approximate _prefix
>
> (the rest of that completer style is just for example, but you probably
> want at least _complete in there after your special one).
>
> It might also be possible to do this more generically with a "matcher"
> zstyle in the context :completion::complete:-command-::* but I'll leave
> that for someone else to work out.  (It'd have to use "zstyle -e" and
> some kind of test similar to the "if" above.)

You can probably do this a bit less fragilely with $zsh_eval_context:

% print -l $(echo .(e:'reply=($zsh_eval_context)':))
cmdsubst
globqual
toplevel


-- 
Mikael Magnusson

Re: context for globbing qualifiers based on command

[Mikael Magnusson]

On 29 February 2012 19:32, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 29 February 2012 19:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> (It wasn't necessary to send this inquiry twice.  It sometimes takes a
>> little while for a response.)
>>
>> On Feb 27, 11:20am, Martin Richter wrote:
>>>
>>> Is it possible to tweak the completion such that shell functions are
>>> grouped at the top when pressing TAB when using (:e...) on a given command?
>>>   print -l *(e:TAB --> gives a lot of possible functions etc
>>> but
>>>   special_command *(e:TAB
>>> gives only shell function matching some regexp or gives only the single
>>> function 'foo' or members of an array of functions?
>>
>> Unfortunately, no.  The zstyle context after *(e: is identical to the
>> context in any other command position.
>>
>> However, the $words array hasn't been altered, so you could write a
>> function to be installed in your "completer" style that examines the
>> values of $words[1] and $words[CURRENT], something like this:
>>
>> _special_command_glob_completer() {
>>  if [[ CURRENT -gt 1 &&
>>        "$words[1]" = 'special_command' &&
>>        "$words[CURRENT]" = *\(*e:* ]]
>>  then
>>    compset -p ${#words[CURRENT]}
>>    compadd -J special-globbers sum_equals product_equals
>>    return 0
>>  else
>>    return 1
>>  fi
>> }
>>
>> zstyle ':completion:*' completer _expand \
>>        _special_command_glob_completer \
>>        _complete _match _ignored _approximate _prefix
>>
>> (the rest of that completer style is just for example, but you probably
>> want at least _complete in there after your special one).
>>
>> It might also be possible to do this more generically with a "matcher"
>> zstyle in the context :completion::complete:-command-::* but I'll leave
>> that for someone else to work out.  (It'd have to use "zstyle -e" and
>> some kind of test similar to the "if" above.)
>
> You can probably do this a bit less fragilely with $zsh_eval_context:
>
> % print -l $(echo .(e:'reply=($zsh_eval_context)':))
> cmdsubst
> globqual
> toplevel

Ignore that :).

-- 
Mikael Magnusson

Re: context for globbing qualifiers based on command

[Bart Schaefer]

On Feb 29,  7:28pm, Martin Richter wrote:
}
} > (It wasn't necessary to send this inquiry twice.  It sometimes takes a
} > little while for a response.)
} Oh, I'm very sorry! I had a look at
}   http://www.zsh.org/mla/workers/2012/index.html
} and couldn't find the post

Try "users" rather than "workers" ...

   http://www.zsh.org/mla/users/2012/index.html

The users list is forwarded to subscribers of workers, but is not
archived with the workers mail.

} and therefore thought I messed up the sending
} somehow. Please excuse me -- I didn't mean to be rude.

That's OK, you meant well. :-)