PATCH: Re: Menu selection movement weirdnesses

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> I think I'm up to date, I know there was a complist patch this morning...

That's old behaviour, comes from the when-wrapping-go-{left,right,...}.

> I have a completion list with 4 columns by 10 rows... that's probably not
> important, what probably is, is that there is a gap at the bottom right,
> i.e. there are 39 entries.  With menu selection, various weird movements
> seem to happen:
> 
> - going up from the top of column four (the last) goes to the bottom of
>   column two, not three;

That's because it was first going up, placing the cursor on the last
item of the third column, then it tested if it had wrapped araound and 
because it had, went left.

> - going left from the bottom of column one goes to the previous line but in
>   column three, not column four.

Similar to the first case.

> - going down from the end of column four (the second last line, with
>   nothing underneath) goes to the last entry in column three.  It's hard
>   to say whether it should go to the top of column four or column one, but
>   I don't think the current behaviour is right.  I suppose it should mirror
>   the behaviour of moving up from the top of column one and move to the top
>   of column four, given that the current implementation never does both
>   a vertical and horizontal wrap in the same move.

I disagree here, having worked quite hard to achieve this. It's more
like moving in emacs: it remembers the column it would like to be in,
then you move down and this is really a line-movement, so it goes to
the next line and places the cursor as near to the last column it was
in as it can. If you continue moving down, so that the cursor moves
into the first line, the cursor is placed in the last column
again. And that only because of the aforementioned change, it did that 
before, because it remembers it once was in that column.

So, I don't want to change it, but if enough people come shouting at
me, I may do that, probably using other widgets for the different
behaviour. It's the decision between line- and column-oriented
movement, I think. But please note that the column-orientation you
expect can't really be achieved as soon as there are multiple groups
with different numbers of columns (that's the reason why I wrote this
original-column-memory).


Bye
 Sven

Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.19
diff -u -r1.19 complist.c
--- Src/Zle/complist.c	2000/05/25 07:58:44	1.19
+++ Src/Zle/complist.c	2000/05/25 11:31:11
@@ -1949,8 +1949,12 @@
 		    continue;
 	    } while (!*p || *p == mtexpl);
 
-	    if (wrap == 1)
-		goto left;
+	    if (wrap == 1) {
+		if (mcol == wishcol)
+		    goto left;
+
+		wishcol = mcol;
+	    }
 	} else if (cmd == Th(z_emacsforwardword) ||
 		   cmd == Th(z_viforwardword) ||
 		   cmd == Th(z_viforwardwordend) ||
@@ -2104,8 +2108,12 @@
 	    } while (!*p || *p == mtexpl || (mcol != omcol && *p == *op));
 	    wishcol = mcol;
 
-	    if (wrap == 2)
+	    if (wrap == 2) {
+		p += mcols - 1 - mcol;
+		wishcol = mcol = mcols - 1;
+		adjust_mcol(wishcol, &p, NULL);
 		goto up;
+	    }
 	} else if (cmd == Th(z_beginningofbufferorhistory) ||
 		   cmd == Th(z_beginningofline) ||
 		   cmd == Th(z_beginningoflinehist) ||

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx