zsh-users
 help / color / mirror / code / Atom feed
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: 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 <gotar@polanet.pl> 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.


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