zsh-users
 help / color / mirror / code / Atom feed
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.

  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).