PATCH: Re: Lots of flickering in menu-selection, and a send-break problem

PATCH: Re: Lots of flickering in menu-selection, and a send-break problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> It goes by too fast for me to see what's really happening, but try this.
> 
> Start a menu selection with a large number of completions, enough to fill
> most of the screen or even to require scrolling.
> 
> Now hit ESC-x to invoke execute-named-command.
> 
> Now abort that with C-g (send-break).
> 
> You get a bunch of flickering and then you're thrown back to the PS1 prompt
> with the current command aborted.  Ick!  I just wanted to get out of the
> execute: prompt, not blow away the whole command line.

The problem was that getkeycmd() returned undefined-key for a aborted
execute-named-command and menu-selection didn't catch that.

Dunno if the patch gives you what you want, but it's the cleanest
implementation I can think of.

> You get similar flickering if you abort out of a scrolling menu-selection
> with C-u (kill-whole-line).  I don't see the flicker when not scrolling.

Ick. No patch for this yet. Menu-selection redisplays the (part of
the) list again without the mark when it's finished. That's a good
thing, I think. But then kill-whole-line comes and clears the list
again (same happens with all the other widgets that clear the list).

I think adding a ZLE_* flag that says that the widget clears the
screen and testing the flag in menu-selection to avoid re-displaying
the list is the best solution. A problem might be the functions that
clear the list only in some cases...

Bye
 Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.9
diff -u -r1.9 complist.c
--- Src/Zle/complist.c	2000/04/27 08:23:33	1.9
+++ Src/Zle/complist.c	2000/04/27 08:53:08
@@ -2034,6 +2034,8 @@
 	    setwish = 1;
 	    mline = -1;
 	    continue;
+	} else if (cmd == Th(z_undefinedkey)) {
+	    continue;
 	} else {
 	    ungetkeycmd();
 	    break;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Re: Lots of flickering in menu-selection, and a send-break problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 27,  3:27pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Re: Lots of flickering in menu-selection, and a send-b
> }
> } cursor-wrap-around suggested by Bart, which seemed even more sensible
> } after thinking about it. The only irritating effect is that moving
> } left when at the top-left match wraps you around to the bottom-right
> } match. Is that how pine works?
> 
> Pine doesn't work very consistently in this regard; it does one thing in
> some selection lists and another thing in others.  The most common rule
> for up/down seems to be not to wrap at all; and, left/right never go past
> the first/last item, so they change lines only in the middle of the list.
> 
> On one screen where pine has multiple selection lists, up/down can "fall
> off" the current list and take you up or down entire categories, but left/
> right still can't go past the first/last item in the current list.

I almost thought so, and I prefer it to, I think it's a case where a
bit of inconsistency reduces the number of surprises.

So this makes it wrap around in at most one dimension.

Bye
 Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.11
diff -u -r1.11 complist.c
--- Src/Zle/complist.c	2000/04/27 13:40:52	1.11
+++ Src/Zle/complist.c	2000/04/28 07:35:23
@@ -1809,12 +1809,23 @@
 		   cmd == Th(z_downlineorhistory) ||
 		   cmd == Th(z_downlineorsearch) ||
 		   cmd == Th(z_vidownlineorhistory)) {
+	    int omline;
+	    Cmatch **op;
+
 	    wrap = 0;
 
 	down:
 
+	    omline = mline;
+	    op = p;
+
 	    do {
 		if (mline == mlines - 1) {
+		    if (wrap & 2) {
+			mline = omline; 
+			p = op;
+			break;
+		    }
 		    p -= mline * mcols;
 		    mline = 0;
 		    wrap |= 1;
@@ -1832,12 +1843,23 @@
 		   cmd == Th(z_uplineorhistory) ||
 		   cmd == Th(z_uplineorsearch) ||
 		   cmd == Th(z_viuplineorhistory)) {
+	    int omline;
+	    Cmatch **op;
+
 	    wrap = 0;
 
 	up:
 
+	    omline = mline;
+	    op = p;
+
 	    do {
 		if (!mline) {
+		    if (wrap & 2) {
+			mline = omline; 
+			p = op;
+			break;
+		    }
 		    mline = mlines - 1;
 		    p += mline * mcols;
 		    wrap |= 1;
@@ -1948,17 +1970,22 @@
 	    p = lp;
 	} else if (cmd == Th(z_forwardchar) || cmd == Th(z_viforwardchar)) {
 	    int omcol;
-	    Cmatch *op;
+	    Cmatch **op;
 
 	    wrap = 0;
 
 	right:
 
 	    omcol = mcol;
-	    op = *p;
+	    op = p;
 
 	    do {
 		if (mcol == mcols - 1) {
+		    if (wrap & 1) {
+			p = op;
+			mcol = omcol;
+			break;
+		    }
 		    p -= mcol;
 		    mcol = 0;
 		    wrap |= 2;
@@ -1966,24 +1993,29 @@
 		    mcol++;
 		    p++;
 		}
-	    } while (!*p || (mcol != omcol && *p == op));
+	    } while (!*p || (mcol != omcol && *p == *op));
 	    wishcol = mcol;
 
 	    if (wrap == 2)
 		goto down;
 	} else if (cmd == Th(z_backwardchar) || cmd == Th(z_vibackwardchar)) {
 	    int omcol;
-	    Cmatch *op;
+	    Cmatch **op;
 
 	    wrap = 0;
 
 	left:
 
 	    omcol = mcol;
-	    op = *p;
+	    op = p;
 
 	    do {
 		if (!mcol) {
+		    if (wrap & 1) {
+			p = op;
+			mcol = omcol;
+			break;
+		    }
 		    mcol = mcols - 1;
 		    p += mcol;
 		    wrap |= 2;
@@ -1991,7 +2023,7 @@
 		    mcol--;
 		    p--;
 		}
-	    } while (!*p || (mcol != omcol && *p == op));
+	    } while (!*p || (mcol != omcol && *p == *op));
 	    wishcol = mcol;
 
 	    if (wrap == 2)

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Re: Lots of flickering in menu-selection, and a send-break problem

[Bart Schaefer]

On Apr 27,  3:27pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: Lots of flickering in menu-selection, and a send-b
}
} cursor-wrap-around suggested by Bart, which seemed even more sensible
} after thinking about it. The only irritating effect is that moving
} left when at the top-left match wraps you around to the bottom-right
} match. Is that how pine works?

Pine doesn't work very consistently in this regard; it does one thing in
some selection lists and another thing in others.  The most common rule
for up/down seems to be not to wrap at all; and, left/right never go past
the first/last item, so they change lines only in the middle of the list.

On one screen where pine has multiple selection lists, up/down can "fall
off" the current list and take you up or down entire categories, but left/
right still can't go past the first/last item in the current list.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Re: Lots of flickering in menu-selection, and a send-break problem

[Sven Wischnowsky]

I wrote:

> Bart Schaefer wrote:
> 
> ...
> 
> > You get similar flickering if you abort out of a scrolling menu-selection
> > with C-u (kill-whole-line).  I don't see the flicker when not scrolling.
> 
> Ick. No patch for this yet. Menu-selection redisplays the (part of
> the) list again without the mark when it's finished. That's a good
> thing, I think. But then kill-whole-line comes and clears the list
> again (same happens with all the other widgets that clear the list).
> 
> I think adding a ZLE_* flag that says that the widget clears the
> screen and testing the flag in menu-selection to avoid re-displaying
> the list is the best solution. A problem might be the functions that
> clear the list only in some cases...

Or we just make sure that the screen isn't cleared before that last
list-display done by menu-selection, just as we do while
menu-selection is active.

Yes, I know, not a really nice solution, but it's such a sweet little
patch: the first hunk of the patch below, the rest is for the changed
cursor-wrap-around suggested by Bart, which seemed even more sensible
after thinking about it. The only irritating effect is that moving
left when at the top-left match wraps you around to the bottom-right
match. Is that how pine works?

Bye
 Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.10
diff -u -r1.10 complist.c
--- Src/Zle/complist.c	2000/04/27 08:55:07	1.10
+++ Src/Zle/complist.c	2000/04/27 13:22:45
@@ -1458,7 +1458,7 @@
 	amatches = oamatches;
 	return 1;
     }
-    if (inselect)
+    if (inselect || mlbeg >= 0)
 	clearflag = 0;
 
     mscroll = 0;
@@ -1571,7 +1571,7 @@
     Thingy cmd;
     Menustack u = NULL;
     int i = 0, acc = 0, wishcol = 0, setwish = 0, oe = onlyexpl, wasnext = 0;
-    int space, lbeg = 0, step = 1;
+    int space, lbeg = 0, step = 1, wrap;
     char *s;
 
     if (fdat || (dummy && (!(s = getsparam("MENUSELECT")) ||
@@ -1809,10 +1809,15 @@
 		   cmd == Th(z_downlineorhistory) ||
 		   cmd == Th(z_downlineorsearch) ||
 		   cmd == Th(z_vidownlineorhistory)) {
+	    wrap = 0;
+
+	down:
+
 	    do {
 		if (mline == mlines - 1) {
 		    p -= mline * mcols;
 		    mline = 0;
+		    wrap |= 1;
 		} else {
 		    mline++;
 		    p += mcols;
@@ -1820,14 +1825,22 @@
 		if (adjust_mcol(wishcol, &p, NULL))
 		    continue;
 	    } while (!*p);
+
+	    if (wrap == 1)
+		goto right;
 	} else if (cmd == Th(z_uphistory) ||
 		   cmd == Th(z_uplineorhistory) ||
 		   cmd == Th(z_uplineorsearch) ||
 		   cmd == Th(z_viuplineorhistory)) {
+	    wrap = 0;
+
+	up:
+
 	    do {
 		if (!mline) {
 		    mline = mlines - 1;
 		    p += mline * mcols;
+		    wrap |= 1;
 		} else {
 		    mline--;
 		    p -= mcols;
@@ -1835,6 +1848,9 @@
 		if (adjust_mcol(wishcol, &p, NULL))
 		    continue;
 	    } while (!*p);
+
+	    if (wrap == 1)
+		goto left;
 	} else if (cmd == Th(z_emacsforwardword) ||
 		   cmd == Th(z_viforwardword) ||
 		   cmd == Th(z_viforwardwordend) ||
@@ -1893,7 +1909,9 @@
 	} else if (cmd == Th(z_beginningofhistory)) {
 	    int ll;
 	    Cmatch **lp;
+
 	top:
+
 	    ll = mline;
 	    lp = p;
 	    while (mline) {
@@ -1911,7 +1929,9 @@
 	} else if (cmd == Th(z_endofhistory)) {
 	    int ll;
 	    Cmatch **lp;
+
 	bottom:
+
 	    ll = mline;
 	    lp = p;
 	    while (mline < mlines - 1) {
@@ -1927,33 +1947,55 @@
 	    mline = ll;
 	    p = lp;
 	} else if (cmd == Th(z_forwardchar) || cmd == Th(z_viforwardchar)) {
-	    int omcol = mcol;
-	    Cmatch *op = *p;
+	    int omcol;
+	    Cmatch *op;
+
+	    wrap = 0;
+
+	right:
 
+	    omcol = mcol;
+	    op = *p;
+
 	    do {
 		if (mcol == mcols - 1) {
 		    p -= mcol;
 		    mcol = 0;
+		    wrap |= 2;
 		} else {
 		    mcol++;
 		    p++;
 		}
 	    } while (!*p || (mcol != omcol && *p == op));
 	    wishcol = mcol;
+
+	    if (wrap == 2)
+		goto down;
 	} else if (cmd == Th(z_backwardchar) || cmd == Th(z_vibackwardchar)) {
-	    int omcol = mcol;
-	    Cmatch *op = *p;
+	    int omcol;
+	    Cmatch *op;
 
+	    wrap = 0;
+
+	left:
+
+	    omcol = mcol;
+	    op = *p;
+
 	    do {
 		if (!mcol) {
 		    mcol = mcols - 1;
 		    p += mcol;
+		    wrap |= 2;
 		} else {
 		    mcol--;
 		    p--;
 		}
 	    } while (!*p || (mcol != omcol && *p == op));
 	    wishcol = mcol;
+
+	    if (wrap == 2)
+		goto up;
 	} else if (cmd == Th(z_beginningofbufferorhistory) ||
 		   cmd == Th(z_beginningofline) ||
 		   cmd == Th(z_beginningoflinehist) ||

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de