Zsh Mailing List Archive
Messages sorted by:
Re: compset -q oddities
- X-seq: zsh-workers 39304
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: compset -q oddities
- Date: Mon, 12 Sep 2016 23:28:53 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=NnWXGa/RuUUV5DFlxEqrNQiZzcf1pptGfIMbzCW5CeE=; b=H869//AFdZFNyaIquI9pXUm6VD72CxHENVTYD7P9Qax7Mn2MD88cD5NVS8+d4x7aXE xAC/r2lNtEMy4glaCc1uN2bD0ibMff9MwEiDtE4nQnLnIv8hNjLXThSbzjNiLJRFlan2 02MCEu6pliuesu48QW7vtGDTKkQhWUfMlcoVUexTSk1FtZt/nZMpOrxJjEH4Hi/oqfP4 8E4NQABHT8HgolXGbCnaIPJVn22+fD5A2UC4XQOzcIsfBkek5IjR9PY5qCs9AZQVkK3O vmwikEvko0TjIrHKkBf7EFkZjIz1s+VAuXeDXHmh6OeHdk4vzHOxiClZQRPTcMpDxBze NnQw==
- In-reply-to: <20160912230632.GA29577@fujitsu.shahaf.local2>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20160911073031.GA19137@fujitsu.shahaf.local2> <160911191422.ZM21970@torch.brasslantern.com> <20160912230632.GA29577@fujitsu.shahaf.local2>
On Sep 12, 11:06pm, Daniel Shahaf wrote:
} Subject: Re: compset -q oddities
} Thanks, but I don't understand how any of those examples constitutes
} a "pilot error" or an empty word.
Some clarification, then:
} In #1, "~~~" is a complete word; completion changed it to "~~~~~~" which
} is also a complete word but wasn't a candidate completion.
You didn't start from ~~~. You started from an empty word and typed
TAB twice. ~~~ was never on the line. I concur that the result of
the second attempt is weird, I would have expected it just to fail.
On the first tab (empty word), the prefix is empty but "compset -q"
causes completion to believe there is quoting on the line (backslash
by default). The compadd call makes ~~~ a valid completion, which
when added is quoted to \~\~\~. The effect of compset is then undone,
meaning the backslash-quoting that was presumed removed is restored,
and you end up with \\\~\\\~\\\~.
On the second tab, one level of quoting is removed by compset to get
\~\~\~ as the prefix. Again compadd inserts \~\~\~ which does match
the prefix, so it's a valid completion, but somewhere along the line
all the \~ go back to \\\~ and now \~ doesn't match any more and so
instead of being discarded because it's already present in the prefix,
it gets appended and you end up with \\\~\\\~\\\~\\\~\\\~\\\~.
This happens for any compadd containing a tilde, it doesn't have to
be the first character in the word. So something wonky is going on
with the handlng of tildes. Actually the same thing happens with a
leading "=" (tilde can be anywhere), so it's quotestring() that is
contributing to the mahem (the large "else if" condition on lines
} In #2 and #3, the input is a prefix of a valid command line ("g
} $'\'foo\''" and "h "$'foo'"" respectively).
No, that's not what I meant. The *word* being completed is meant to
be a partial command line, not the whole buffer. I know that the doc
says "split on spaces into separate words, respecting the usual shell
quoting conventions" but the implementation calls set_comp_sep() which
"splits the current word as if it were a command line". But read on.
} #2 does not involve an
} empty word; the word there is "'" (a single-byte word).
Also not quite true; the word in both #2 and #3 is an un-closed quoted
string. The result of that parse is not well-defined.
I also don't know any circumstance in which it would be correct to call
"compset -q" twice in succession as you did in #3.
However, on closer inspection I don't think there's actually anything
wrong with the results if the debug warnings are ignored, unlike the
case with #1.
} Thanks again for the explanation. I'd like to understand what the
} expected behaviour here is. They triggered DPUTS calls so I assumed
} they were bugs.
This one --
compcore.c:1657: expecting 'x' at offset 2 of "'x"
-- seems to be a legit problem with counting bytes when looking for an
unbalanced $'...'. I don't think fixing that would change the outcome,
that is $'\' --> \' (see quoting converted, above). I'm not confident
of how to fix it; PWS was last here in workers/22026 (git 34381548).
For this --
utils.c:6826: BUG: unterminated $' substitution
-- my line numbers seem to be off-by-20 from yours, but its the same
commit as the previous bug, and it's correct about the unterminated
$'...', so it's probably a spurious DPUTS.
Messages sorted by: