Re: Solution: Bu report - unix/_gpg completion broken

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote on Wed, 10 Jun 2020 01:07 +0200:
> On 6 Jun, Daniel Shahaf wrote:
> > --- a/Completion/compinit
> > @@ -159,6 +159,7 @@ _comp_options=(
> > +    NO_shfileexpansion  
> 
> Stuffing extra options into _comp_options is usually a bad idea because
> it prevents the completion system from honouring the user's preferences.
> In this case _expand will no longer handle the correct precedence of ~
> and brace expansion.

Oh, sorry.  I looked for such side effects before I made the change,
but didn't find any.  Should I revert that patch pending a better one?

In any case, I think the long term fix here isn't to expect completion
functions to be able to run under arbitrary syntax-modifying options —
especially given that some completion functions are maintained outside
our own tree by people not as familiar with the spectrum of syntax
variations as folks on this list — but to run completion functions
under a known set of options and make the user's options available to
them separately.  That's exactly what we would necessarily do if
completion functions didn't happen to be executed by the same
interpreter that will later executed $PREBUFFER$BUFFER.

z-sy-h has code for this.  It synthesizes an associative array akin to
$options, but it doesn't require zsh/parameter.

Cheers,

Daniel

P.S.  OT: Does anyone use a zsh build where the zsh/parameter module is
not available [i.e., where «zmodload zsh/parameter» would fail]?

> It looks to me like the shfileexpansion option has got broken more
> fundamentally at some point. Swap the = and : in the character
> class in the pattern on the line that produces an error and the error
> goes away. _complete_debug also appears to be broken with
> shfileexpansion:
> 
>   setopt shfileexpansion; : =(echo hi)
> 
> I've not bisected fully but I did check a very old zsh and it worked
> fine with that.
> 
> Oliver
>