Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Regression in braces completion
- X-seq: zsh-workers 25879
- From: Peter Stephenson <pws@xxxxxxx>
- To: "Zsh Hackers' List" <zsh-workers@xxxxxxxxxx>
- Subject: Re: Regression in braces completion
- Date: Mon, 13 Oct 2008 17:27:50 +0100
- In-reply-to: <081013084328.ZM28630@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20a807210810111932r1b32b746l3cca788a383e84ed@xxxxxxxxxxxxxx> <081011213249.ZM29979@xxxxxxxxxxxxxxxxxxxxxx> <081012001051.ZM30706@xxxxxxxxxxxxxxxxxxxxxx> <20081012204236.6669a668@pws-pc> <081012154721.ZM22722@xxxxxxxxxxxxxxxxxxxxxx> <20081013100417.36870ba5@news01> <081013084328.ZM28630@xxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
> However, I'm not sure the C code is actually wrong here. Postulate a
> completer that given "abcd" as the thing to match, returns "zyxw" and
> uses compadd -U to say "accept this as a completion even though it does
> not look like what you started with." Now call that completer for a
> line with "abc{d". Is the right answer really "zyx{w" ?
Yes, if the C code has (as it does) stripped all the stuff to do with
the parts of the brace expansion it doesn't think you want to see away
before you ever got to look at the word to be completed. Otherwise you
get a meaningless hybrid---you're adding back braces you've never had
any information about in the first place.
(I can see how you could argue it differently: you can infer the braces
by looking at the raw command line and tell the completion system that
you've decided you don't like what's done and decide to do it yourself.
However, that's overloading -U with multiple meanings: not just "use my
completion as it is in your results table" but "forget everything you've
done so far and insert this the way I want". I'm not convinced it even
works---the system is now thoroughly confused about what it's actually
completing, so working out what it's replacing with your string isn't
easy. What -U does and doesn't do is already rather obscure, so this is
all probably moot.)
I think to do it consistently with the other interpretation, you would
need completion internally to ignore the presence of braces right from
the start and allow the function system to decide whether to handle
them. That's not going to happen any time soon---though it's actually
possible it's a more elegant solution.
> I wasn't suggesting treating this as a special case, I was suggesting
> that _path_files treat a spelling correction in the path prefix as a
> special case. That's the stated reason why _path_files is using -U.
As you previously noted, there are already far too many ways of running
compadd within _path_files as it is. I'm not at all happy about
doubling the number to get sets with and without -U --- which would
leave spelling correction broken in the case where braces are present
(perhaps depending which way the pinball decides to roll down
_path_files in that case, but I presume it would still miss the
flippers in the same way).
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author