From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Cc: martin.ebourne@arcordia.com
Subject: PATCH: Re: Delaying menu completion
Date: Tue, 14 Aug 2001 14:02:04 +0200 [thread overview]
Message-ID: <15225.4924.267164.433795@gargle.gargle.HOWL> (raw)
In-Reply-To: <OF282F56AE.F70B2E05-ON80256AA8.002E05E6@uk.jpmorgan.com>
martin.ebourne@arcordia.com wrote:
> ...
>
> > The caveat I mentioned is that _approximate has this strange test in it:
> > [[ "${#compstate[unambiguous]}" -ge "${#:-$PREFIX$SUFFIX}" ]]
> > That means that the unambiguous prefix must be longer than the word on
> > the command line. I.e., there's no way to prevent it dropping into
> > menu completion unless all the matches have a common prefix longer than
> > what's on the line right now. I don't remember what that was supposed
> > to accomplish, but it seems a rather unlikely situation. Sven?
We had some discussion about this twice, I think. My hope was that it
would use normal (non-menu) completion only if there was some sensible
unambiguous prefix. That, based somehow on the original string.
I think I mentioned that I wasn't sure about this even when I first
wrote it... noone came up with anything better.
> I had previously discovered this and tried removing that condition but it
> still didn't work properly. However, armed with the now working match above
> I've managed to get it to do what I want. With the patch below, I can set
> insert-unambiguous to 'always' and then it never enters menu completion,
> which is exactly what I'm after.
>
> Someone will need to check the patch because I don't fully understand
> what's going on - its a combination of cut & paste and trial & error coding
> in there. ;)
I was thinking about the same yesterday. I just wasn't sure if we
shouldn't remove that test completely, or make a `true' value keep it
always from starting menu completion and add some other value for a --
probably improved -- test to use normal completion when there is a
sensible unambiguous string.
So I'd have changed it to either:
if zstyle -t "..." insert-unambiguous; then
compstate[pattern_insert]=unambiguous
elif _requested ...
or
zstyle -s "..." insert-unambiguous ins
if [[ $ins = (true|yes|on|1) ||
( $ins = sometimes &&
$compstate[unambiguous] -is sensible ) ]]; then
compstate[pattern_insert]=unambiguous
elif _requested ...
What do people think? Should we make `always' normal the meaning of
insert-unambiguous==true? Keep the test? Making it be used on a new
special value would of course do no harm.
> ...
>
> But 'zle is-completing' wasn't giving the return code (although the info
> pages say it will).
Ah. Humm. That's caused by completecall() (in zle_tricky.c). The
problem is that the completion widgets normally return non-zero if no
matches were generated and the code there tries to ensure that even
for user defined completion widgets. I.e., it specifically replaces
the zero returned from a user-defined widget with a `1' to signal that
completion `failed'. That's ugly in cases like this one, yes, but I
don't know if we should change it.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next prev parent reply other threads:[~2001-08-14 12:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-14 9:21 martin.ebourne
2001-08-14 12:02 ` Sven Wischnowsky [this message]
2001-08-14 16:03 ` Bart Schaefer
2001-08-14 12:24 martin.ebourne
2001-08-16 9:51 martin.ebourne
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=15225.4924.267164.433795@gargle.gargle.HOWL \
--to=wischnow@informatik.hu-berlin.de \
--cc=martin.ebourne@arcordia.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).