From: Alan <8fvebtoeq87@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: menu-select doesn't respect COMPLETE_IN_WORD option
Date: Sun, 14 Jun 2020 00:28:37 -0400 [thread overview]
Message-ID: <CAL7A0-Mye7pcAVdhFT0tcc3XAoHOokY7qAQqo-tgN=bs1cNPOw@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7Y1gnTGA0hWf7o5ffTdor17EQE1PTGe_YrqkxvWGk72rQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]
Thanks for your help with this Bart!
When I leave completeinword unset, _prefix completion simply doesn't work,
even if I have:
zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix
Or if I have:
zstyle ':completion:*' completer _expand _prefix _complete _ignored
(I also don't have alwaystoend set.)
One additional thing I've found to be really strange about _prefix
completion is if there is only one possible match. For example:
% ls -a
./ ../
% mkdir -p dir1/dir2/dir3
% ls dir1/di_r2/dir3<menu-complete> (<-- where _ is the position of the
cursor)
% ls dir1_ (<-- the "/dir2/dir3" part of the line has been removed!)
% ls dir1/dir2/di_r3<menu-complete> (<-- where _ is the position of the
cursor)
% ls dir1_ (<-- same thing happens)
% ls di_r1/dir2/dir3<menu-complete> (<-- where _ is the position of the
cursor)
% ls dir1_r1 (<-- where _ is the position of the cursor. The suffix only
until the first slash, "r1", has been kept after the cursor, but the
"/dir2/dir3" part of the suffix has been removed!)
When there are more than one possible completions, this doesn't happen and
_prefix completion works normally by the previously stated behavior (i.e.
keeps the entire suffix after the cursor, but completes/cycles only on the
prefix).
Seems like when there is only one possible match, the definition of prefix
and suffix gets thrown out the window... possibly a bug?
On Sat, Jun 13, 2020 at 11:07 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:
> On Wed, Jun 10, 2020 at 8:26 PM Alan <8fvebtoeq87@gmail.com> wrote:
> >
> > Yes, I've tried *not* setting the complete_in_word option, but then the
> _prefix completer doesn't work. See this (rather bizarre in my opinion)
> explanation from http://zsh.sourceforge.net/Guide/zshguide06.html:
> >
> > "One gotcha with the _prefix completer: you have to make sure the option
> COMPLETE_IN_WORD is set. That may sound counter-intuitive: after all,
> _prefix forces completion not to complete inside a word. The point is that
> without that option, completion is only ever tried at the end of the word,
> so when you type <TAB> in the middle of <prefix><suffix>, the cursor is
> moved to after the end of the suffix before the completion system has a
> chance to see what's there, and hence the whole thing is regarded as a
> prefix, with no suffix."
>
> As you've noticed, I think this advice only applies when _prefix is
> attempted after _complete, or possibly when the ALWAYS_TO_END option
> is set (which by default it is not). I don't think COMPLETE_IN_WORD
> is relevant unless you want prefixes completed only when no other
> possibility is found (which is probably what it was thought most
> people would expect).
>
> If someone has a chance to test a few combinations and update that
> doc, please go ahead. I might but I don't know how soon.
>
> > (I'm not actually entirely clear how the completer ordering works, so
> not sure if I need that second _prefix instance at the end, but whatever
> works I guess. If someone would care to shed some light on the matter, that
> would be good too.)
>
> The completion process happens in a nested loop: For each function in
> the completer list, try it with each of the patterns in the
> matcher-list. Ordinarily this loop stops as soon as one of the
> completers returns zero (true), which is why the order is important,
> but the _all_matches completer can change that.
>
> The only reason to put _prefix in the list twice would be to implement
> the example of doing so that appears in the documentation for _prefix.
>
next prev parent reply other threads:[~2020-06-14 4:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 23:56 Alan
2020-06-10 1:11 ` Bart Schaefer
2020-06-10 1:53 ` Alan
2020-06-10 2:25 ` Alan
2020-06-11 2:33 ` Bart Schaefer
2020-06-11 3:26 ` Alan
2020-06-14 3:07 ` Bart Schaefer
2020-06-14 4:28 ` Alan [this message]
2020-06-15 0:37 ` Bart Schaefer
2020-06-15 5:09 ` 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='CAL7A0-Mye7pcAVdhFT0tcc3XAoHOokY7qAQqo-tgN=bs1cNPOw@mail.gmail.com' \
--to=8fvebtoeq87@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-users@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).