zsh-users
 help / color / mirror / code / Atom feed
From: Tomasz Pala <gotar@polanet.pl>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: cd /u/N/v/ tab expansion
Date: Sun, 17 Apr 2022 18:17:27 +0200	[thread overview]
Message-ID: <20220417161727.GA31153@polanet.pl> (raw)
In-Reply-To: <CAH+w=7ZNqbZFT6919d4=FQdvzA0_iR336WXyBLAmpZGCmwaxkQ@mail.gmail.com>

On Sat, Apr 16, 2022 at 20:00:18 -0700, Bart Schaefer wrote:

>> > $ cd /e/s/s/[tab]
>> > No matches for: `directory'
>>
>> This happens with: setopt glob_complete interfering with
>>
>> zstyle ':completion:*' list-dirs-first true
> 
> I am not able to reproduce this with zsh-5.8.1.2-test-9-g0ad3b11, at
> least not with only:
> 
> zstyle '*' format %d
> zstyle ':completion:*' list-dirs-first true
> zstyle ':completion:*:*:*:*' list-suffixes yes
> setopt globcomplete

I might look for the other options involved if that matters, to provide
minimal config, however since you see the effect in scenario below I
guess the above one is only some compound side-effect (as this is also
fixed/masked by any of my 2 proposals, either "gs" or "-U").

>> $ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
>> $ ls a/b/d/e/g[tab]
>> No matches for: `files' or `directory'
> 
> This I am able to reproduce with the settings above.
> 
> However, if I invoke _next_tags at that point, I get:
> 
> % ls a/b/d/e/g
> directory
> b1/d/e/g  b2/d/e/g
> 
> So the results have been correctly completed and added, they're just
> not in the tag group where they appear on the first attempt.

This is why "-U" alone also "fixes" my case as far as I understand (?).

> The settings of list-dirs-first and list-suffixes have no effect on
> the tag to which the matches are added in this case.  It's all down to
> globcomplete.  _next_tags works here, too.
> 
> When globcomplete is set, the following differences occur:
> _path_files line 251 forces menu=yes
> _path_files line 737 sets SUFFIX=*/d/e/g*
> _path_files returns false to _files line 119, so ret=0 is not done at line 120
> _files line 109 invokes _tags which calls comptags -N
> _files returns false to _arguments, so ret=0 is not done at line 465
> _arguments line 467 sets alwopt=yes
> _arguments line 538 test is true, so 543-551 run compadd
> _arguments line 586 is false, returns false to _dispatch, no ret=0 at line 63
> _dispatch returns false to _complete, no ret=0 at line 117
> _complete returns false _main_complete

This is far beyond my skills on completion flow tracking...

> As you mention in a later message on this this thread, one problem is
> at _path_files line 737, that suffix will never match given that the
> /e/ path segment is ambiguous.  Using :gs as you suggested resolves
> everything after that, but introduces a new difference at
> _main_compete:411, where compstate[pattern_match]='*' and
> unambiguous_cursor=8 (instead of 4 in the noglobcomplete case).  That
> seems to go along with having forced menu completion on, but it seems
> odd.

During some tests I did saw a 'weird' jumping of cursor from 'b'
position forward after a tab, just like the single disambiguation took
over and chosen both (AFAIR), but I didn't record the scenario.

> Regarding:
>> -             compadd "$tmp4[@]" $listopts - "$i"
>> +             compadd "$tmp4[@]" -U $listopts - "$i"
> 
> Try ${Uopt} instead of -U there, and see if that makes any difference?

I've already tried this without success.


> I don't seem to be able to re-create the setup for your "ctrl-g
> toggling of behaviour" incident.  Can you specify?

Sure, minimal config that exposes this "state-leaking":


setopt glob_complete

autoload -U compinit
compinit

zstyle ':completion:*' completer _complete _prefix
zstyle ':completion:*' add-space true
zstyle ':completion:*' menu select=long-list select=1
zstyle ':completion:*:*:*:*' list-suffixes yes


with _no_ "-U" added in _path_files (i.e. "-U" apparently fixes this one).
Note the 'add-space' style is optional, but enabled makes the problem
more viable ("toggleable").


With list-dirs-first working properly for "middle part ambiguosity" I
might simply disable the list-suffixes, however this is suspicious
itself to toggle results between consecutive completions.

best regards,
-- 
Tomasz Pala <gotar@pld-linux.org>


  reply	other threads:[~2022-04-17 18:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 12:40 zzapper
2022-04-07 20:11 ` Bart Schaefer
2022-04-07 20:20   ` zzapper
2022-04-07 23:11     ` Bart Schaefer
2022-04-08  9:53       ` zzapper
2022-04-08 17:57         ` Bart Schaefer
2022-04-08 10:22       ` david rayner
2022-04-08 18:09         ` Bart Schaefer
2022-04-10  1:04       ` Tomasz Pala
2022-04-10 14:32         ` Tomasz Pala
2022-04-10 16:27           ` Tomasz Pala
2022-04-10 16:32             ` Tomasz Pala
2022-04-10 17:45               ` Tomasz Pala
2022-04-10 18:05                 ` Tomasz Pala
2022-04-16 14:17                   ` Tomasz Pala
2022-04-17  3:00           ` Bart Schaefer
2022-04-17 16:17             ` Tomasz Pala [this message]
2022-04-17 18:15               ` Bart Schaefer
2022-04-17 18:44                 ` Bart Schaefer
2022-04-17 18:32               ` 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=20220417161727.GA31153@polanet.pl \
    --to=gotar@polanet.pl \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    --subject='Re: cd /u/N/v/ tab expansion' \
    /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

Code repositories for project(s) associated with this 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).