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 10:04:17 +0100	[thread overview]
Message-ID: <20081013100417.36870ba5@news01> (raw)
In-Reply-To: <081012154721.ZM22722@torch.brasslantern.com>

On Sun, 12 Oct 2008 15:47:19 -0700
Bart Schaefer <schaefer@brasslantern.com> 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


  reply	other threads:[~2008-10-13  9:05 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 [this message]
2008-10-13 15:43           ` Bart Schaefer
2008-10-13 16:27             ` Peter Stephenson
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=20081013100417.36870ba5@news01 \
    --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).