From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 723 invoked from network); 25 May 2000 11:32:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 May 2000 11:32:07 -0000 Received: (qmail 28868 invoked by alias); 25 May 2000 11:31:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11569 Received: (qmail 28860 invoked from network); 25 May 2000 11:31:44 -0000 Date: Thu, 25 May 2000 13:31:38 +0200 (MET DST) Message-Id: <200005251131.NAA02378@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Thu, 25 May 2000 11:30:34 +0100 Subject: PATCH: Re: Menu selection movement weirdnesses 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@informatik.hu-berlin.de