From: Bart Schaefer <firstname.lastname@example.org> To: Tomasz Pala <email@example.com> Cc: Zsh Users <firstname.lastname@example.org> Subject: Re: cd /u/N/v/ tab expansion Date: Sun, 17 Apr 2022 11:15:21 -0700 [thread overview] Message-ID: <CAH+w=7YBKZyMbBkB+jcu9NvhdLa6OpB_4uohGcJpoYt21vRRaQ@mail.gmail.com> (raw) In-Reply-To: <20220417161727.GA31153@polanet.pl> On Sun, Apr 17, 2022 at 9:17 AM Tomasz Pala <email@example.com> wrote: > > On Sat, Apr 16, 2022 at 20:00:18 -0700, Bart Schaefer wrote: > > > 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 This is the trigger again, the other settings just make it possible to see the difference. I'm again suspicious of menu=yes being forced on by _path_files for globcomplete. On the first tab, menu completion is entered. When you hit ctrl+g, you exit menu completion, but do not exit/restart the ZLE editor. That leaves $_lastcomp initialized, so when you hit tab again, _main_complete line 83 sees that the word on the line has not changed and therefore deliberately re-enters completion with the state from the previous attempt. Even though the command line shows the cursor at the end of the word, the unambiguous_cursor position is used, which splits the word into SUFFIX=/g and PREFIX=a/b/d/e and the rest of the behavior follows from that. The next ctrl+g has the same effect -- leaves menu completion but leaves $_lastcomp alone -- so the behavior isn't really "toggling". What's different on the third (and fifth, etc.) tab presses is that the last trial completion ("a/b/d/e /g" with space) is no longer the same as the word on the line ("a/b/d/e/g"), so _main_complete behaves as if you've started a whole new completion, which generates the same menu as the first tab. The important part here is that it is not wrong (in most cases) to re-enter completion with the preserved state when the word on the line has not changed, so resetting _lastcomp is not the answer. One possible fix is this: diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_co mplete index 169ca1f40..4ab572894 100644 --- a/Completion/Base/Core/_main_complete +++ b/Completion/Base/Core/_main_complete @@ -82,7 +82,8 @@ fi if [[ "$compstate[pattern_match]" = "*" && "$_lastcomp[unambiguous]" = "$PREFIX" && - -n "$_lastcomp[unambiguous_cursor]" ]]; then + -n "$_lastcomp[unambiguous_cursor]" && + "$CURSOR" -eq "$_lastcomp[unambiguous_cursor]" ]]; then integer upos="$_lastcomp[unambiguous_cursor]" SUFFIX="$PREFIX[upos,-1]$SUFFIX" PREFIX="$PREFIX[1,upos-1]" However, I'm concerned that will negatively affect behavior in other circumstances, particularly when always_to_end is set or complete_in_word is not set. The question to be answered is whether Tomasz's expection that ctrl+g will reset the state is correct, and if so, how to make that happen when exiting menu completion that way.
next prev parent reply other threads:[~2022-04-17 18:16 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 2022-04-17 18:15 ` Bart Schaefer [this message] 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=7YBKZyMbBkB+jcu9NvhdLa6OpB_4uohGcJpoYt21vRRaQ@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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).