From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@math.gatech.edu
Subject: BUG: Extended completion with alternative completion
Date: Mon, 2 Nov 1998 01:29:27 -0800 [thread overview]
Message-ID: <981102012927.ZM6545@candle.brasslantern.com> (raw)
I'm fooling with the compctl for cdmatch from Misc/compctl-examples:
compctl -K cdmatch -S '/' -q -x 'p[2]' -Q -K cdmatch2 - \
'S[/][~][./][../]' -g '*(-/)' + -g '*(-/D)' - \
'n[-1,/]' -K cdmatch -S '/' -q -- cd chdir pushd
With this compctl installed (and no others except the 3.1.5 defaults, which
are essentially none), from the zsh-3.1.5 directory, the following setopts:
noautomenu off
completealiases off
completeinword on <-- This is important
globcomplete off
menucomplete off
I type:
zagzig<7> cd S/M
Now back up so the cursor is on the `S' and press TAB. The n[-1,/] case is
chosen correctly by get_ccompctl() and returned to makecomplist(). At this
point we hit the following code:
/* *compadd is the number of characters we have to ignore at the *
* beginning of the word. */
wb += *compadd;
s += *compadd;
if ((offs -= *compadd) < 0)
/* It's bigger than our word prefix, so we can't help here... */
return 1;
offs <= *compadd, so 1 is returned to docompletion() at this code:
/* Make sure we have the completion list and compctl. */
if(makecomplist(s, incmd, &delit, &compadd, untokenized)) {
/* Error condition: feeeeeeeeeeeeep(). */
feep();
goto compend;
}
At this point we feep() and fail, mistakenly believing that an error has
occurred. This appears harmless until the compctl is modified like so:
compctl -K cdmatch -S '/' -q -x 'p[2]' -Q -K cdmatch2 - \
'S[/][~][./][../]' -g '*(-/)' + -g '*(-/D)' - \
'n[-1,/]' -K cdmatch -S '/' -q -- + -K cdmatch -S '/' -q \
cd chdir pushd ^^^^^^^^^^^^^^^^^^^^^^^
There are two problems: (1) in get_ccompctl(), when we chose to return
the n[] completion, we lose track of the alternative (which hangs off
the xor pointer in the head of the linked list of -x patterns); (2) we're
prematurely returning an error in makecomplist(), so even if we still had
the handle to the xor, we'd never follow it.
In short, alternative completion only works with extended completion when
none of the extended patterns match, which doesn't seem right to me.
It's not hard to fix (2), but I'm leery of messing with (1) when there are
a lot of other pending completion patches to be folded in to 3.1.6. Sven,
are you out there?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next reply other threads:[~1998-11-02 9:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-02 9:29 Bart Schaefer [this message]
1998-11-02 11:43 Sven Wischnowsky
1998-11-02 17:20 ` 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=981102012927.ZM6545@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@math.gatech.edu \
/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).