From: Bart Schaefer <schaefer@brasslantern.com>
To: Alan <8fvebtoeq87@gmail.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: menu-select doesn't respect COMPLETE_IN_WORD option
Date: Sun, 14 Jun 2020 17:37:30 -0700 [thread overview]
Message-ID: <CAH+w=7aiQNO+-1EG2EyrH0JAMienH+aLQ+k9O27E8eTD0RmJFg@mail.gmail.com> (raw)
In-Reply-To: <CAL7A0-Mye7pcAVdhFT0tcc3XAoHOokY7qAQqo-tgN=bs1cNPOw@mail.gmail.com>
On Sat, Jun 13, 2020 at 9:28 PM Alan <8fvebtoeq87@gmail.com> wrote:
>
> When I leave completeinword unset, _prefix completion simply doesn't work, even if I have:
>
> zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix
>
> 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!)
Starting from "zsh -f" and like you using "_" for cursor position:
% compinit -D
% zstyle \* format %d
% zstyle ':completion:*' menu 'select=1'
% zstyle ':completion:*' completer _expand _prefix _complete _ignored
% mkdir -p dir1/dir2/dir3
% ls dir1/di_r2/dir3
% ls dir1/dir2/dir3/_
The above happens with any of complete-word, expand-or-complete, or
menu-complete.
If I run expand-or-complete-prefix instead:
% ls dir1/di_r2/dir3
% ls dir1/dir2/_r2/dir3
Which looks exactly like I would expect.
% set -o | grep complete
completealiases off
completeinword off
globcomplete off
menucomplete off
If I turn on "globcomplete" then nothing works except
expand-or-complete-prefix, but I still don't get anything removed from
the line. I just get a beep and the cursor stays in the middle of
"dir2" and the description "files" appears (from the format zstyle).
If I turn on "completeinword" then I can reproduce your described
behavior with menu-complete, although expand-or-complete-prefix still
works as expected. Looking at the output of ^x? (complete-debug),
what's happening is that _prefix says "if there is only one possible
completion, then insert only the unambiguous prefix" which (because of
the way completing across a directory boundary works) is only "dir1".
This does not occur if you are completing a file name in the current
directory:
% touch part1.part2.part3
% ls part1.pa_rt2.part3
% ls part1.part2.part3_rt2.part3
So I still think you want to leave complete-in-word turned off and
find out what other part of your startup is breaking things when you
do.
Incidentally the _prefix behavior with the unambiguous prefix is
itself a compromise; before workers/18841 (2003-07-09) it would
alarmingly delete the entire word from the line.
next prev parent reply other threads:[~2020-06-15 0:38 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
2020-06-15 0:37 ` Bart Schaefer [this message]
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='CAH+w=7aiQNO+-1EG2EyrH0JAMienH+aLQ+k9O27E8eTD0RmJFg@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=8fvebtoeq87@gmail.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).