Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
cc: Danek Duvall <duvall@comfychair.org>
In-reply-to: <160226114511.ZM17604@torch.brasslantern.com>
From: Oliver Kiddle <okiddle@yahoo.co.uk>
References: <20160226175937.GA22547@lorien.comfychair.org> <160226114511.ZM17604@torch.brasslantern.com>
To: Zsh workers <zsh-workers@zsh.org>
Subject: Re: reverse-menu-complete re-starting completion on 5.2?
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8455.1456706751.1@thecus.kiddle.eu>
Date: Mon, 29 Feb 2016 01:45:52 +0100
Message-ID: <8456.1456706752@thecus.kiddle.eu>

Bart wrote:
> On Feb 26,  9:59am, Danek Duvall wrote:
> } I can cycle forward through the directories
> } just fine, but when I switch into reverse, it takes whatever directory is
> } on the command line and starts completing its subdirectories backwards.
> } Absolutely not what I want.
> 
> This appears to have resulted from this commit:

Even before that commit I can reproduce a variant of the problem by
starting menu completion with reverse-menu-complete and then switching
to a forwards menu complete.

The code only enables cycling of matches when the condition
compwidget == lastcompwidget holds. Before 35627 reverse-menu-complete
was done quite differently and bypassed this code.

One possible fix is to force menucmp to 2 for reversemenucomplete as
follows:
  @@ -346,6 +346,7 @@ reversemenucomplete(char **args)
      zmult = -zmult;
  +    if (menucmp == 1) menucmp = 2;

Apart from that not working for the case of going from reverse to
forwards menu completion, I'm really not sure why we need to be so
strict about the completion widget matching the last completion widget.
With menu selection, we switch to the menuselect keymap and any
completion style widget advances to the next match. I can see why it
would have seemed logical but can't come up with a realistic scenario
where the strict checking of the condition is in any way useful. Can
anyone foresee any problem with just relaxing the condition (see patch).

Oliver

diff --git a/Src/Zle/compcore.c b/Src/Zle/compcore.c
index ae3a640..ae7068f 100644
--- a/Src/Zle/compcore.c
+++ b/Src/Zle/compcore.c
@@ -30,10 +30,6 @@
 #include "complete.mdh"
 #include "compcore.pro"
 
-/* The last completion widget called. */
-
-static Widget lastcompwidget;
-
 /* Flags saying what we have to do with the result. */
 
 /**/
@@ -471,8 +467,7 @@ before_complete(UNUSED(Hookdef dummy), int *lst)
 
     /* If we are doing a menu-completion... */
 
-    if (minfo.cur && menucmp && *lst != COMP_LIST_EXPAND && 
-	(menucmp != 1 || !compwidget || compwidget == lastcompwidget)) {
+    if (minfo.cur && menucmp && *lst != COMP_LIST_EXPAND) {
 	do_menucmp(*lst);
 	return 1;
     }
@@ -481,7 +476,6 @@ before_complete(UNUSED(Hookdef dummy), int *lst)
 	onlyexpl = listdat.valid = 0;
 	return 1;
     }
-    lastcompwidget = compwidget;
 
     /* We may have to reset the cursor to its position after the   *
      * string inserted by the last completion. */
diff --git a/Src/Zle/complist.c b/Src/Zle/complist.c
index 162436b..8aeb6c3 100644
--- a/Src/Zle/complist.c
+++ b/Src/Zle/complist.c
@@ -3399,7 +3399,7 @@ domenuselect(Hookdef dummy, Chdata dat)
 	do_single(*(minfo.cur));
     }
     if (wasnext || broken) {
-	menucmp = 2;
+	menucmp = 1;
 	showinglist = ((validlist && !nolist) ? -2 : 0);
 	minfo.asked = 0;
 	if (!noselect) {
diff --git a/Src/Zle/zle_tricky.c b/Src/Zle/zle_tricky.c
index cc4b7d6..a89b2a3 100644
--- a/Src/Zle/zle_tricky.c
+++ b/Src/Zle/zle_tricky.c
@@ -100,8 +100,7 @@ mod_export int usemenu, useglob;
 /**/
 mod_export int wouldinstab;
 
-/* != 0 if we are in the middle of a menu completion. May be == 2 to force *
- * menu completion even if using different widgets.                        */
+/* != 0 if we are in the middle of a menu completion. */
 
 /**/
 mod_export int menucmp;