From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: compset -q oddities
Date: Mon, 12 Sep 2016 23:28:53 -0700 [thread overview]
Message-ID: <160912232853.ZM27002@torch.brasslantern.com> (raw)
In-Reply-To: <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
5824-5836).
} 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.
next prev parent reply other threads:[~2016-09-13 6:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-11 7:30 Daniel Shahaf
2016-09-12 2:14 ` Bart Schaefer
2016-09-12 23:06 ` Daniel Shahaf
2016-09-13 6:28 ` Bart Schaefer [this message]
2016-09-13 10:21 ` Peter Stephenson
2016-09-14 17:56 ` Bart Schaefer
2016-09-15 5:10 ` Daniel Shahaf
2016-09-16 0:40 ` Bart Schaefer
2016-09-16 3:05 ` [PATCH] Etc/BUGS: Remove fixed items, add 'compset -q' item from workers/39306 Daniel Shahaf
2016-09-16 5:00 ` Bart Schaefer
2016-09-14 3:22 ` compset -q oddities Daniel Shahaf
2016-09-14 5:20 ` Bart Schaefer
2016-09-14 6:12 ` Daniel Shahaf
2016-09-14 14:59 ` Bart Schaefer
2016-09-14 19:52 ` Oliver Kiddle
2016-09-15 3:08 ` Bart Schaefer
2016-09-14 8:31 ` Peter Stephenson
2016-09-14 16:04 ` Bart Schaefer
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=160912232853.ZM27002@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/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).