zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Zsh workers <zsh-workers@zsh.org>
Cc: Danek Duvall <duvall@comfychair.org>
Subject: Re: reverse-menu-complete re-starting completion on 5.2?
Date: Mon, 29 Feb 2016 01:45:52 +0100	[thread overview]
Message-ID: <8456.1456706752@thecus.kiddle.eu> (raw)
In-Reply-To: <160226114511.ZM17604@torch.brasslantern.com>

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;


       reply	other threads:[~2016-02-29  0:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160226175937.GA22547@lorien.comfychair.org>
     [not found] ` <160226114511.ZM17604@torch.brasslantern.com>
2016-02-29  0:45   ` Oliver Kiddle [this message]
2016-03-06 17:41     ` Bart Schaefer
2016-03-07  2:05       ` Mikael Magnusson
2016-03-09 11:12         ` Mikael Magnusson
2016-03-09 11:41           ` Mikael Magnusson
2016-03-09 22:45             ` Bart Schaefer
2016-03-10  2:19               ` Mikael Magnusson

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=8456.1456706752@thecus.kiddle.eu \
    --to=okiddle@yahoo.co.uk \
    --cc=duvall@comfychair.org \
    --cc=zsh-workers@zsh.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).