Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Regression in braces completion
- X-seq: zsh-workers 25873
- From: Peter Stephenson <pws@xxxxxxx>
- To: "Zsh Hackers' List" <zsh-workers@xxxxxxxxxx>
- Subject: Re: Regression in braces completion
- Date: Mon, 13 Oct 2008 10:04:17 +0100
- In-reply-to: <081012154721.ZM22722@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: CSR
- References: <20a807210810111932r1b32b746l3cca788a383e84ed@xxxxxxxxxxxxxx> <081011213249.ZM29979@xxxxxxxxxxxxxxxxxxxxxx> <081012001051.ZM30706@xxxxxxxxxxxxxxxxxxxxxx> <20081012204236.6669a668@pws-pc> <081012154721.ZM22722@xxxxxxxxxxxxxxxxxxxxxx>
On Sun, 12 Oct 2008 15:47:19 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> In order to find the possible completions of the rightmost expansion
> of the brace expression, the C code removes everything between the
> brace and the comma, inclusive, and then asks the completer (which
> happens to be _path_files) for the matches. It's not expecting the
> completer to modify the command line as a side-effect, but that's
> what happens when "compadd -U" is called.
No, that's not how "compadd -U" works. It simply changes the rules of how
completions added by the command are treated. The actual modification of
the command line happens later in any case. It's very roughly like this:
- completion system kicks off a set of functions
- somewhere inside those compadd is called
- within the C code some internal variables are updated to add lists of
things grouped together in horribly obscure ways, storing the fact that
"-U" was present
- eventually the completion function exits
- the code in compresult.c uses the previous results to decide how to
manipulate the command line.
As the compresult code is called a lot later than the "compadd" and there's
no clear grouping of variables used by it, it's extremely difficult to pin
changes in the result onto changes in the command that added the
completion, particularly since the whole thing is sensitive (via what's
visible as compstate etc.) to context (although different context shouldn't
be an issue here). One of the things that's taken account of at various
places along the line, including in the compresult code that adds ambiguous
or unambiguous completions, is whether -U was present (except that it's
called something entirely different internally that I've forgotten).
It's certainly possible that the code that takes account of braces in the
case of compadd -U isn't present because it's never been tested before, but
that would be bug: the C code takes pains to hide the existence of the
braces from the rest of the system, so there's no way you can treat this as
a special case anywhere else, and if you did it would arbitrarily limit the
completions you could do on expressions with braces.
pws
Messages sorted by:
Reverse Date,
Date,
Thread,
Author