From: Bart Schaefer <schaefer@brasslantern.com> To: Tomasz Pala <gotar@polanet.pl> Cc: Zsh Users <zsh-users@zsh.org> Subject: Re: cd /u/N/v/ tab expansion Date: Sat, 16 Apr 2022 20:00:18 -0700 [thread overview] Message-ID: <CAH+w=7ZNqbZFT6919d4=FQdvzA0_iR336WXyBLAmpZGCmwaxkQ@mail.gmail.com> (raw) In-Reply-To: <20220410143222.GA21848@polanet.pl> On Sun, Apr 10, 2022 at 7:32 AM Tomasz Pala <gotar@polanet.pl> wrote: > > On Sun, Apr 10, 2022 at 03:04:41 +0200, Tomasz Pala wrote: > > > $ cd /e/s/s/[tab] > > No matches for: `directory' > > This happens with: setopt glob_complete interfering with > > zstyle ':completion:*' list-dirs-first true > > According to the docs this should not be correlated. 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 > $ 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 behaviour also doesn't match the docs - enabling list-suffixes > should cause all ambiguous components to be shown. Apparently it does > the opposite (!) 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 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. Regarding: > - compadd "$tmp4[@]" $listopts - "$i" > + compadd "$tmp4[@]" -U $listopts - "$i" Try ${Uopt} instead of -U there, and see if that makes any difference? I don't seem to be able to re-create the setup for your "ctrl-g toggling of behaviour" incident. Can you specify?
next prev parent reply other threads:[~2022-04-17 3:01 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 [this message] 2022-04-17 16:17 ` Tomasz Pala 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='CAH+w=7ZNqbZFT6919d4=FQdvzA0_iR336WXyBLAmpZGCmwaxkQ@mail.gmail.com' \ --to=schaefer@brasslantern.com \ --cc=gotar@polanet.pl \ --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).