zsh-users
 help / color / mirror / Atom feed
* menu-select doesn't respect COMPLETE_IN_WORD option
@ 2020-06-09 23:56 Alan
  2020-06-10  1:11 ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Alan @ 2020-06-09 23:56 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Hi,

I have COMPLETE_IN_WORD set, but menu-select doesn't respect it. In my
~/.zshrc:

setopt completeinword
zmodload -i zsh/complist
zstyle ':completion:*' menu select=1

Example:

% ls dir/
bigfile bigfile1 smallfile
% ls dir/big_blahblah <where _ is the cursor position in the middle of the
text "bigblahblah" with no spaces, then execute menu-select>
No matches for: `files'

What I want to happen:
% ls dir/bigfile_blahblah <where _ is the cursor position>
files
bigfile bigfile1
(Then executing menu-select again switches to bigfile1 with the "blahblah"
part still appended:)
% ls dir/bigfile1_blahblah <where _ is the cursor position>
files
bigfile bigfile1

Is there any way to do this?

Thanks!

--Alan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-09 23:56 menu-select doesn't respect COMPLETE_IN_WORD option Alan
@ 2020-06-10  1:11 ` Bart Schaefer
  2020-06-10  1:53   ` Alan
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2020-06-10  1:11 UTC (permalink / raw)
  To: Alan; +Cc: Zsh Users

On Tue, Jun 9, 2020 at 4:58 PM Alan <8fvebtoeq87@gmail.com> wrote:
>
> I have COMPLETE_IN_WORD set, but menu-select doesn't respect it.

You're misunderstanding what COMPLETE_IN_WORD does.  It tries to match
both the leading and trailing parts.

What you want is to invoke the expand-or-complete-prefix widget
instead of the default expand-or-complete.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-10  1:11 ` Bart Schaefer
@ 2020-06-10  1:53   ` Alan
  2020-06-10  2:25     ` Alan
  0 siblings, 1 reply; 10+ messages in thread
From: Alan @ 2020-06-10  1:53 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

I see, yes, you're correct.

I like the expand-or-complete-prefix widget and have it bound to tab. Is
there a way to make menu-complete/menu-select behave like
expand-or-complete-prefix (i.e. complete just what is to the left of the
cursor and ignore anything to the right, as shown in my first email)?


On Tue, Jun 9, 2020 at 9:11 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Tue, Jun 9, 2020 at 4:58 PM Alan <8fvebtoeq87@gmail.com> wrote:
> >
> > I have COMPLETE_IN_WORD set, but menu-select doesn't respect it.
>
> You're misunderstanding what COMPLETE_IN_WORD does.  It tries to match
> both the leading and trailing parts.
>
> What you want is to invoke the expand-or-complete-prefix widget
> instead of the default expand-or-complete.
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-10  1:53   ` Alan
@ 2020-06-10  2:25     ` Alan
  2020-06-11  2:33       ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Alan @ 2020-06-10  2:25 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

I found a partial solution by adding the _prefix completer (along with the
complete_in_word option). However, as you said, the complete_in_word option
also matches the trailing part when using menu-complete/select, which I
don't prefer. It does work when the trailing part doesn't match anything
though.


On Tue, Jun 9, 2020 at 9:53 PM Alan <8fvebtoeq87@gmail.com> wrote:

> I see, yes, you're correct.
>
> I like the expand-or-complete-prefix widget and have it bound to tab. Is
> there a way to make menu-complete/menu-select behave like
> expand-or-complete-prefix (i.e. complete just what is to the left of the
> cursor and ignore anything to the right, as shown in my first email)?
>
>
> On Tue, Jun 9, 2020 at 9:11 PM Bart Schaefer <schaefer@brasslantern.com>
> wrote:
>
>> On Tue, Jun 9, 2020 at 4:58 PM Alan <8fvebtoeq87@gmail.com> wrote:
>> >
>> > I have COMPLETE_IN_WORD set, but menu-select doesn't respect it.
>>
>> You're misunderstanding what COMPLETE_IN_WORD does.  It tries to match
>> both the leading and trailing parts.
>>
>> What you want is to invoke the expand-or-complete-prefix widget
>> instead of the default expand-or-complete.
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-10  2:25     ` Alan
@ 2020-06-11  2:33       ` Bart Schaefer
  2020-06-11  3:26         ` Alan
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2020-06-11  2:33 UTC (permalink / raw)
  To: Alan; +Cc: Zsh Users

On Tue, Jun 9, 2020 at 7:26 PM Alan <8fvebtoeq87@gmail.com> wrote:
>
> I found a partial solution by adding the _prefix completer (along with the complete_in_word option).

Have you tried NOT setting the complete_in_word option?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-11  2:33       ` Bart Schaefer
@ 2020-06-11  3:26         ` Alan
  2020-06-14  3:07           ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Alan @ 2020-06-11  3:26 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

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

However, after reading that section on _prefix more carefully, I tried
putting the _prefix completer further up in my completer list right after
_expand (in ~/.zshrc) like so:

zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix

...and now it works (mostly) the way I prefer! Namely, it acts like
expand-or-complete-prefix and ignores the suffix, even if the suffix
matches something. There is still some weirdness with slashes at the end of
directories, so that I get double slashes sometimes when the suffix starts
with a slash, but I suppose that's something I can live with.

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


On Wed, Jun 10, 2020 at 10:33 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Tue, Jun 9, 2020 at 7:26 PM Alan <8fvebtoeq87@gmail.com> wrote:
> >
> > I found a partial solution by adding the _prefix completer (along with
> the complete_in_word option).
>
> Have you tried NOT setting the complete_in_word option?
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-11  3:26         ` Alan
@ 2020-06-14  3:07           ` Bart Schaefer
  2020-06-14  4:28             ` Alan
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2020-06-14  3:07 UTC (permalink / raw)
  To: Alan; +Cc: Zsh Users

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-14  3:07           ` Bart Schaefer
@ 2020-06-14  4:28             ` Alan
  2020-06-15  0:37               ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Alan @ 2020-06-14  4:28 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-14  4:28             ` Alan
@ 2020-06-15  0:37               ` Bart Schaefer
  2020-06-15  5:09                 ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2020-06-15  0:37 UTC (permalink / raw)
  To: Alan; +Cc: Zsh Users

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: menu-select doesn't respect COMPLETE_IN_WORD option
  2020-06-15  0:37               ` Bart Schaefer
@ 2020-06-15  5:09                 ` Bart Schaefer
  0 siblings, 0 replies; 10+ messages in thread
From: Bart Schaefer @ 2020-06-15  5:09 UTC (permalink / raw)
  To: Alan; +Cc: Zsh Users

On Sun, Jun 14, 2020 at 5:37 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> 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:
>
> If I turn on "completeinword" then I can reproduce your described
> behavior with menu-complete, although expand-or-complete-prefix still
> works as expected. [...]
>
> 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.

Ignore that last part, sorry.  I just realized that when you wrote
"_prefix completion simply doesn't work" you did not mean that
completion failed, you just mean that it did something you didn't want
it to, and that "something" is probably exactly what I described it
doing.

This documentation is in fact correct: "One gotcha with the _prefix
completer: you have to make sure the option COMPLETE_IN_WORD is set."

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-06-15  5:10 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-09 23:56 menu-select doesn't respect COMPLETE_IN_WORD option 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
2020-06-15  5:09                 ` Bart Schaefer

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git