bindkey '^Xi' insert-all-matches And then type: ls ^Xi There is an error message: _pick_variant:19: bad math expression: operand expected at `|| 0 ) ' I'm using zsh 5.8 on Arch Linux. -- Best regards, lilydjwg
On 9/28/20, lilydjwg <lilydjwg@gmail.com> wrote:
> bindkey '^Xi' insert-all-matches
>
> And then type:
>
> ls ^Xi
>
> There is an error message:
>
> _pick_variant:19: bad math expression: operand expected at `|| 0 ) '
>
> I'm using zsh 5.8 on Arch Linux.
You should either complain to the person who wrote insert-all-matches,
or provide the code here, otherwise nobody has any chance to guess
what's wrong.
--
Mikael Magnusson
> On 28 September 2020 at 17:30 Mikael Magnusson <mikachu@gmail.com> wrote:
> On 9/28/20, lilydjwg <lilydjwg@gmail.com> wrote:
> > bindkey '^Xi' insert-all-matches
> >
> > And then type:
> >
> > ls ^Xi
> >
> > There is an error message:
> >
> > _pick_variant:19: bad math expression: operand expected at `|| 0 ) '
> >
> > I'm using zsh 5.8 on Arch Linux.
>
> You should either complain to the person who wrote insert-all-matches,
> or provide the code here, otherwise nobody has any chance to guess
> what's wrong.
While I was thinking that, I suspect that, whatever's causing this, changing
$precommands[(I)builtin] on that line to ${precommands[(I)builtin]:-0]} would
probably make it go away...
pws
> On 28 September 2020 at 17:47 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> > On 28 September 2020 at 17:30 Mikael Magnusson <mikachu@gmail.com> wrote:
> > On 9/28/20, lilydjwg <lilydjwg@gmail.com> wrote:
> > > bindkey '^Xi' insert-all-matches
> > >
> > > And then type:
> > >
> > > ls ^Xi
> > >
> > > There is an error message:
> > >
> > > _pick_variant:19: bad math expression: operand expected at `|| 0 ) '
> > >
> > > I'm using zsh 5.8 on Arch Linux.
> >
> > You should either complain to the person who wrote insert-all-matches,
> > or provide the code here, otherwise nobody has any chance to guess
> > what's wrong.
>
> While I was thinking that, I suspect that, whatever's causing this, changing
> $precommands[(I)builtin] on that line to ${precommands[(I)builtin]:-0]} would
> probably make it go away...
And a bit lower down... sorry, should probably have sent this before...
pws
--- a/Completion/Base/Utility/_pick_variant
+++ b/Completion/Base/Utility/_pick_variant
@@ -16,10 +16,10 @@ done
if (( ${#precommands:|builtin_precommands} )); then
pre=command
-elif (( $+opts[-b] && ( $precommands[(I)builtin] || $+builtins[$opts[-c]] ) )); then
+elif (( $+opts[-b] && ( ${precommands[(I)builtin]:-0} || $+builtins[$opts[-c]] ) )); then
(( $+opts[-r] )) && : ${(P)opts[-r]::=$opts[-b]}
return 0
-elif (( $precommands[(I)builtin] )); then
+elif (( ${precommands[(I)builtin]:-0} )); then
pre=builtin
else
# Neither builtin nor command-forcing precommand specified,
On Mon, Sep 28, 2020 at 6:51 PM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> -elif (( $precommands[(I)builtin] )); then
> +elif (( ${precommands[(I)builtin]:-0} )); then
Doesn't $precommands[(I)builtin] always expand to an integer (as long
as precommands is an array)? In which case can it expand to null?
Roman.
> On 28 September 2020 at 18:02 Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> On Mon, Sep 28, 2020 at 6:51 PM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > -elif (( $precommands[(I)builtin] )); then
> > +elif (( ${precommands[(I)builtin]:-0} )); then
>
> Doesn't $precommands[(I)builtin] always expand to an integer (as long
> as precommands is an array)? In which case can it expand to null?
Yes, I would guess for some reason precommands isn't an array here.
That might mean the context isn't set up the way completion usually
expects it, of course, in which case this isn't the proper fix.
pws
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --] I'm sorry I thought it came with zsh, but it turned out that I got it from a zsh-users message. The code is _insert_all_matches () { setopt localoptions nullglob rcexpandparam extendedglob noshglob unsetopt markdirs globsubst shwordsplit nounset ksharrays compstate[insert]=all compstate[old_list]=keep _complete } zle -C insert-all-matches complete-word _insert_all_matches This code has worked for me for a few years until today I noticed that it didn't work well with ls. Mikael Magnusson <mikachu@gmail.com> 于 2020年9月29日周二 00:30写道: > On 9/28/20, lilydjwg <lilydjwg@gmail.com> wrote: > > bindkey '^Xi' insert-all-matches > > > > And then type: > > > > ls ^Xi > > > > There is an error message: > > > > _pick_variant:19: bad math expression: operand expected at `|| 0 ) ' > > > > I'm using zsh 5.8 on Arch Linux. > > You should either complain to the person who wrote insert-all-matches, > or provide the code here, otherwise nobody has any chance to guess > what's wrong. > > -- > Mikael Magnusson > [-- Attachment #2: Type: text/html, Size: 1841 bytes --]
On Mon, Sep 28, 2020 at 10:52 AM lilydjwg <lilydjwg@gmail.com> wrote: > > I'm sorry I thought it came with zsh, but it turned out that I got it from a zsh-users message. Wow. That's from Andrej B. back in 1999/2000. In fact I can't even find the message that actually defines the function, just a couple of the ones that discuss what it might do. > This code has worked for me for a few years until today I noticed that it didn't work well with ls. I can reproduce from zsh -f plus your function. According to _main_complete: # _precommand sets this to indicate we are following a precommand modifier local -a precommands I think the issue is that _insert_all_matches is expecting to be called as a completer from inside _main_complete, not as a standalone widget. If we want _pick_variant to work in this context, we need PWS's patch, but there may be other oddities as well. Perhaps 20 years ago it was OK to call _complete directly like that, but it's not OK any longer.
Bart Schaefer wrote: > I think the issue is that _insert_all_matches is expecting to be > called as a completer from inside _main_complete, not as a standalone > widget. Yes, I think you're right. > If we want _pick_variant to work in this context, we need PWS's patch, > but there may be other oddities as well. Perhaps 20 years ago it was > OK to call _complete directly like that, but it's not OK any longer. To create custom completion widgets that make use of the existing compsys system, bind to _generic and set the completer style. zstyle ':completion:all-matches::::' completer _all_matches _complete zstyle ':completion:all-matches:*' old-matches true zstyle ':completion:all-matches:*' insert true zstyle ':completion:all-matches:*' file-patterns \ '%p:globbed-files' '*(-/):directories' '*:all-files' zle -C all-matches complete-word _generic bindkey '^Xx' all-matches _generic dates to June 2000, _all_matches October of that year and my use of it, more-or-less like this, is the following year. I had zle -C directly binding _history before that but, as indicated in a comment, it was specifically designed to work either way. At some point I switched to using it via _generic too and that's what I'd recommend now. Oliver
On Tue, Sep 29, 2020 at 08:10:15AM +0200, Oliver Kiddle wrote:
> Bart Schaefer wrote:
> > I think the issue is that _insert_all_matches is expecting to be
> > called as a completer from inside _main_complete, not as a standalone
> > widget.
>
> Yes, I think you're right.
>
> > If we want _pick_variant to work in this context, we need PWS's patch,
> > but there may be other oddities as well. Perhaps 20 years ago it was
> > OK to call _complete directly like that, but it's not OK any longer.
>
> To create custom completion widgets that make use of the existing
> compsys system, bind to _generic and set the completer style.
>
> zstyle ':completion:all-matches::::' completer _all_matches _complete
> zstyle ':completion:all-matches:*' old-matches true
> zstyle ':completion:all-matches:*' insert true
> zstyle ':completion:all-matches:*' file-patterns \
> '%p:globbed-files' '*(-/):directories' '*:all-files'
> zle -C all-matches complete-word _generic
> bindkey '^Xx' all-matches
>
> _generic dates to June 2000, _all_matches October of that year and my
> use of it, more-or-less like this, is the following year. I had zle -C
> directly binding _history before that but, as indicated in a comment, it
> was specifically designed to work either way. At some point I switched
> to using it via _generic too and that's what I'd recommend now.
Thanks! This code works without issues. But could zsh include such
a functionality itself, so that users need only to bind a key when they
want? This functionality helps me a lot, e.g. when removing system
packages sharing the same prefix.
BTW the mailing list archive seems not receiving any message after
Aug 2. (I was trying to keep a reference to your message.)
--
Best regards,
lilydjwg
[ Replying to a week old message. ] lilydjwg wrote on Tue, 29 Sep 2020 22:59 +0800: > BTW the mailing list archive seems not receiving any message after > Aug 2. Known issue; we've been short on tuits. The code's already written but we haven't had time to test/deploy it. > (I was trying to keep a reference to your message.) If you mean point others to the message, you can use the X-Seq number for that. If you mean download the message, you can download it from https://www.zsh.org/mla/zsh-workers/. Cheers, Daniel