Thanks for maintaining zsh (again)! zsh menu navigation is confusing and implemented so that it makes reaching the last element in a list of completions extremely difficult. In a multi-column menu of completions, pressing "up" from most items will take the user to the previous item in the list. When an item that is at the top of a column is selected, pressing "up" moves the selection to the last item in the previous column. This is the correct behavior. This does not happen when the users is on first item in the first column. Pressing up from *this* item (and only this item) will take the users to the last item in the first (current) column. It should take the users to the last item in the list (i.e., the last item in the last column). The effect of this is that it can make it very hard to select the last item in a long multi-column menu of completions. For date-based organization of data in a directory, this can be particularly frustrating. Similarly, pressing down from the final column will select the item that is one to the left and one down of the last item rather than the first item (which would be expected). Pressing right from the last item moves to the first column (as would be expected) but also moves one down (which would not). Moving left from the first column acts irregularly as well selecting items that are sometimes one up and sometimes in the second-to-last column (depending on the layout). This should all be normalized so that the normal operating is grid-like movement (as it is in most places that do not involve edges of the grid) and so that moving up from the first item or down from that item moves to the end/beginning.
This seems like a reasonable complaint to me. Is there a reason not to be more grid-like?----- Forwarded message from "Benjamin Hill (Mako)" <mako@debian.org> ----- Thanks for maintaining zsh (again)! zsh menu navigation is confusing and implemented so that it makes reaching the last element in a list of completions extremely difficult. In a multi-column menu of completions, pressing "up" from most items will take the user to the previous item in the list. When an item that is at the top of a column is selected, pressing "up" moves the selection to the last item in the previous column. This is the correct behavior. This does not happen when the users is on first item in the first column. Pressing up from *this* item (and only this item) will take the users to the last item in the first (current) column. It should take the users to the last item in the list (i.e., the last item in the last column). The effect of this is that it can make it very hard to select the last item in a long multi-column menu of completions. For date-based organization of data in a directory, this can be particularly frustrating. Similarly, pressing down from the final column will select the item that is one to the left and one down of the last item rather than the first item (which would be expected). Pressing right from the last item moves to the first column (as would be expected) but also moves one down (which would not). Moving left from the first column acts irregularly as well selecting items that are sometimes one up and sometimes in the second-to-last column (depending on the layout). This should all be normalized so that the normal operating is grid-like movement (as it is in most places that do not involve edges of the grid) and so that moving up from the first item or down from that item moves to the end/beginning.----- End forwarded message -----
This seems like a reasonable complaint to me. Is there a reason not to be more grid-like?----- Forwarded message from "Benjamin Hill (Mako)" <mako@debian.org> ----- Thanks for maintaining zsh (again)! zsh menu navigation is confusing and implemented so that it makes reaching the last element in a list of completions extremely difficult. In a multi-column menu of completions, pressing "up" from most items will take the user to the previous item in the list. When an item that is at the top of a column is selected, pressing "up" moves the selection to the last item in the previous column. This is the correct behavior. This does not happen when the users is on first item in the first column. Pressing up from *this* item (and only this item) will take the users to the last item in the first (current) column. It should take the users to the last item in the list (i.e., the last item in the last column). The effect of this is that it can make it very hard to select the last item in a long multi-column menu of completions. For date-based organization of data in a directory, this can be particularly frustrating. Similarly, pressing down from the final column will select the item that is one to the left and one down of the last item rather than the first item (which would be expected). Pressing right from the last item moves to the first column (as would be expected) but also moves one down (which would not). Moving left from the first column acts irregularly as well selecting items that are sometimes one up and sometimes in the second-to-last column (depending on the layout). This should all be normalized so that the normal operating is grid-like movement (as it is in most places that do not involve edges of the grid) and so that moving up from the first item or down from that item moves to the end/beginning.----- End forwarded message -----
On Jan 10, 3:18pm, Clint Adams wrote: } Subject: [mako@debian.org: Bug#289748: zsh: menu navigation is suboptimal] } } This seems like a reasonable complaint to me. Is there a reason not to } be more grid-like? Sven's preference? This statement is actually not quite correct: } ----- Forwarded message from "Benjamin Hill (Mako)" <mako@debian.org> ----- } } This does not happen when the users is on first item in the first } column. Pressing up from *this* item (and only this item) will take } the users to the last item in the first (current) column. I believe it actually goes to the last item in the *longest* column, which happens always to be the first one. The idea is to jump to the end of the *display*, not the end of the *list*, otherwise some items "below and to the left of" the last item might not be visible when the display is redrawn.
On Jan 10, 3:18pm, Clint Adams wrote: } Subject: [mako@debian.org: Bug#289748: zsh: menu navigation is suboptimal] } } This seems like a reasonable complaint to me. Is there a reason not to } be more grid-like? Sven's preference? This statement is actually not quite correct: } ----- Forwarded message from "Benjamin Hill (Mako)" <mako@debian.org> ----- } } This does not happen when the users is on first item in the first } column. Pressing up from *this* item (and only this item) will take } the users to the last item in the first (current) column. I believe it actually goes to the last item in the *longest* column, which happens always to be the first one. The idea is to jump to the end of the *display*, not the end of the *list*, otherwise some items "below and to the left of" the last item might not be visible when the display is redrawn.
<quote who="Bart Schaefer" date="2005-01-10 20:35:02 +0000"> I really don't care about the going to the next line bits. If it's a grid on the edges, that's fine. But the user should be able to count on up and down arrows to move in a loop. These are really two seperate issues and I guess it's the conflict that I stepped into: * Moving like a grid. * Moving like items in a list. Currently, there is a sort of balance going on. That's fine. The only part that I feel strongly about is that up from the very first item should go to the last item and not to the bottom of the first column. That behavior is not seen anywhere else in the grid and it makes it quite difficult to select the very last item in some situation -- a very common thing. Well, it's the first, longest column. All but the last will be of identical lengths. Regards, Mako
I thought about this a little bit this afternoon and I think I have a little bit to add. <quote who="Benj. Mako Hill" date="2005-01-10 16:20:53 -0500"> The current interface makes a whole lot more sense for two column menus. The situation that has been aggrevating me has been a 6-7 column menu where things are similarly named and I am routinely trying to get to the last item (datestamps). For multiple column menus, zsh's behavior, especially in the first column, becomes increasingly unruly. Going to the longest line makes sense but in a menu where 6/7 of the lines are equally long, it fails to serve a productive purpose and often gets in the way. One idea would be to have things behave slightly differently for 2 column lists and larger than two column lists although I would understand reservations against this. Regards, Mako
You wrote: It is possible to get straight to the last item from the first by using the reverse-menu-complete editor command. I bind that to shift-tab: bindkey '\e[Z' reverse-menu-complete For the behaviour you want, with the up and down keys, you can try the following bindings: bindkey -M menuselect '\e[B' menu-complete bindkey -M menuselect '\e[A' reverse-menu-complete Note that your terminal may generate different escape sequences from those keys. Oliver
Bart Schaefer wrote: I think that's all it is, though there was some discussion at the time. It's probably not too difficult to fix in domenuselect (and possibly adjust_mcol) in complist.c. After all, I counted at least five comments in the 900-odd lines of the function.
Bart Schaefer wrote: I think that's all it is, though there was some discussion at the time. It's probably not too difficult to fix in domenuselect (and possibly adjust_mcol) in complist.c. After all, I counted at least five comments in the 900-odd lines of the function.