From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: menu-select widget interacts badly with interactive style
Date: Fri, 15 Oct 2004 01:53:52 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.61.0410150059560.30712@toltec.zanshin.com> (raw)
I just stumbled upon a bit of confusing behavior that probably warrants
a mention somewhere ... I'm just not sure where.
I have a widget defined with "#compdef -k menu-select ...". This bypasses
_main_complete for that widget because of the implementation of #compdef
in compinit, even though menu-select itself is mapped onto _main_complete.
Most of the time this is OK. (Evidently this is something I should be
doing with _generic instead?)
However, if I also use "zstyle ':completion:*' menu select interactive"
things get interesting.
With this setting, since none of the values is "yes", the automenu rules
are in effect and normal TAB completion produces a listing on the first
TAB and enters menu selection (with interactive mode) on the second TAB.
So far this is all as expected.
When I invoke my own widget before having done any other completions, it
does not start interactive selection, because _main_complete is never
called -- but after I've entered menu selection through TAB completion,
_main_complete leaves the MENUSELECT et al. control variables set. Thus
the *next* time I invoke my menu-select widget, that also starts up in
interactive mode. (I presume the same would apply to search mode.)
It was quite disconcerting for a while there not being able to predict
whether I was going to get interactive mode or not, before I figured out
what was going on.
Another less urgent factor is that the SPACE key breaks out of interactive
menu selection even when there are spaces in some of the possible matches.
In some cases this makes it impossible to disambiguate the match, and one
is forced to (a) remember not to type space because it'll stop completion
and perform self-insert, and (b) use down-history et al. to begin normal
menu selection and navigate to the desired match.
reply other threads:[~2004-10-15 8:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=Pine.LNX.4.61.0410150059560.30712@toltec.zanshin.com \
--to=schaefer@brasslantern.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).