Re: mutt/2019: menu_context itches (Re: your mail)
On Wednesday, August 10, 2005 at 10:49:03 AM -0700, Brendan Cully wrote:
>> [on <last-entry>] Nobody expects to obtain a totally random number
>> of entries
> In fact I do :)
OK. I happen to have _again_ forgotten the scroll=no mode. Grmbl!!
Now I understood your concern, and reproduced it.
Mutt stock 1.5.7 or 1.5.9, $menu_scroll=no $menu_move_off=yes all
rest defaut, 34 lines screen, 41 entries menu.
- <first-entry> shows line 1-34 cursor on 1.
- <next-page> shows 35-41c35.
- <next-page> shows 35-41c41.
- <first-entry><last-entry> directly shows 35-41c41.
That was the legacy: At my big surprise <last-entry> really shows a
"random" between 1 and 34 number of entries, depending on previous
screen position, and identical to a serie of <next-page>s from there.
Now difference with 1.5.9.tamo.menu_onlybug.1:
- <first-entry><last-entry> shows 41-41c41.
Thats's one entry only, always, as soon as screen needed to be
repositioned. That should be corrected, without touching to the
$menu_scroll=yes behaviour which is already sensible and legacy
compliant.
Now what a "repositioning <last-entry>" in $menu_scroll=no mode
could sensibly show is listable:
· a screenfull 8-41c41 (as <last-entry><current-bottom>).
· a half screen 24-41c41 (as <last-entry><current-middle>).
· a single line 41-41c41 (as <last-entry><current-top>).
· a configurable amount of empty margin.
· a random x-41c41 number of entries. Legacy.
It seems (to me) at first level that 3 and 5 are least sensible,
that 1 and 2 are most, that 4 is achievable as a 1 or 3 plus
$menu_indicator_margin, and that we unfortunately are stuck to 5 legacy.
At a second thought that's not so unfortunate, because all results are
obtainable thru 5 plus macros plus margin. And no other first level
behaviour permits all 5 final screens. So 5 legacy may in fact be the
best way to go.
I just hope this reasoning doesn't break on another cursor-driven
screen-repositionning jump behaviour anywhere else. Starting test of
-extra patch in a minute.
> More precisely, I expect the same screen that greeted me when I first
> opened the mailbox.
Folder on open jumps to <first-new-then-unread-then-last>, right?
This should be fixed by the same fix of repositionning after jump as
above.
> very intuitive, as strange as it may sound to you.
When user preferences are concerned, we must always be prepared for
the strangest whishes to be valid. Good lesson. That probably also means
that there are yet valid potential usages blocked by our each own maybe
biased idea that this or that "would be 103% pure bloat".
Bye! Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The Folding@home project at <URL:http://folding.stanford.edu/>.