zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@csr.com>
To: "Zsh Hackers' List" <zsh-workers@sunsite.dk>
Subject: Re: Regression in braces completion
Date: Mon, 13 Oct 2008 17:27:50 +0100	[thread overview]
Message-ID: <200810131627.m9DGRoED017498@news01.csr.com> (raw)
In-Reply-To: <081013084328.ZM28630@torch.brasslantern.com>

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@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


  reply	other threads:[~2008-10-13 16:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-12  2:32 Vin Shelton
2008-10-12  4:32 ` Bart Schaefer
2008-10-12  7:10   ` Bart Schaefer
2008-10-12 19:42     ` Peter Stephenson
2008-10-12 22:47       ` Bart Schaefer
2008-10-13  9:04         ` Peter Stephenson
2008-10-13 15:43           ` Bart Schaefer
2008-10-13 16:27             ` Peter Stephenson [this message]
2008-10-13 16:56               ` Bart Schaefer
2008-10-14  4:37               ` PATCH (?) " Bart Schaefer
2008-10-14  8:45                 ` Peter Stephenson
2008-10-15  1:34                   ` Vin Shelton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810131627.m9DGRoED017498@news01.csr.com \
    --to=pws@csr.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).