<<< Date Index >>>     <<< Thread Index >>>

Re: menu_context question



Hello Charles,

 On Wednesday, September 6, 2006 at 16:22:30 -0700, Charles Killian wrote:

> I have been playing with menu_context and menu_scroll.

    First of all, $menu_context is misnamed: It is not there to give
context lines between page jumps (as $pager_context does in pager), but
to provide a margin around the indicator bar. Hence the now forgotten
and late proposal to rename $menu_context to $menu_indicator_margin.

    An additional feature to give context lines between page jumps makes
full sense, doesn't exist in Mutt, but was already coded by Tamotsu
(look for $menu_jump_context). It should logically be named...
$menu_context, if only the name was not squatted.


> I like the fact that menu_scroll gives good context, but I don't like
> that it only goes down one message at a time.

    Unclear: You mean you prefer to unset $menu_scroll and use
<next-entry>? Or prefer to use <next-page>?


> I like the fact that menu_context allows you to page with context

    Strictly speaking, that's not true: <next-page> provides a fully new
page, without a single line of context. If you see entries #1 to #34,
<next-page> shows lines #35 to #68 with cursor on #40 (35-68c40).

    I assume you're talking about the implicit page jumps eventually
triggered by <next-entry> (and all other indicator-driven movements) in
$menu_scroll=no mode. When you see lines 1-34c29, <next-entry> shows
25-58c30. With 10 lines in common with the previous page (twice the
cursor margin).


> I don't like the fact that it pages before you reach the bottom of the
> screen. (i.e. if the menu_context is set to 5, then when you try to
> move within 5 messages of the bottom, the screen is paged, and your
> cursor becomes the 6th line from the top). Is this property of
> menu_context by design?

    In some way, yes. The intent is to have a margin below (and above)
the indicator. It works beautifully in $menu_scroll=yes mode. And the
current behaviour that you describe and dislike in $menu_scroll=no mode
seems to make (some level of) sense too.

    But wading thru mutt-dev archives could show you that we discussed
and experimented several behaviours, and that this specific case
(cursor-driven implicit jumps in $menu_scroll=no mode with
$menu_context=non-zero) was a little bit like a grey zone. Not many
users expressed any preference, so we took the behaviour that seemed the
most logical to us. But it's sometimes hard to well design modes one
doesn't use in practice. IINM all people involved in this feature's
design were $menu_scroll=yes guys.

    So welcome: You are the guy we want to hear. ;-)


> I would prefer that it not page until you reach the bottom of the
> screen, and then page so that it leaves context at the top.

    Let me rephrase: You would prefer to see lines 1 to 34 cursor on 34,
then <next-entry> shows 30-63c35. With 5 lines of old context. Right?

    At first sight:

 - No way to setup today's Mutt like this, IINM.
 - Seems against the "margin" concept.
 - Non immediatly reversible: <previous-entry> would have to be pressed
6 times to come back to previous page. When today 1 time suffices.
 - Anyway 6*<previous-entry> would not exactly reverse to 1-34c34, but
to 1-34c29.

    I'm not convinced. The scheme is:

 -1) Explicit page jumps (<{previous,next}-page>, <half-{up,down}) are
not themselves subject to margin, but push the cursor by margin. They
should gain a way to keep some context lines.

 -2) Cursor-driven movements (<{previous,next}-{entry,undeleted,mmf}>,
<search>, <search-{reverse,next,opposite}>, numeric <jump>, an so on...)
in scroll mode are clearly subject to margin. They push the page border
by margin.

 -3) Cursor-driven movements in no-scroll mode also push the page
border, by margin or more. Triggering implicit page jumps. With context
lines kept only as a happy side effect of simply requiring the cursor
bar to be on the target entry *and* inside the visible screen.

    This seems a good scheme to me: Simple, flexible, and logic.


Bye!    Alain.
-- 
Microsoft Outlook Express users concerned about readability: For much better
viewing quotes in your messages, check the little freeware program OE-QuoteFix
by Dominik Jain. It'll change your life. :-) Exists also for Outlook.
See <URL:http://home.in.tum.de/~jain/software/oe-quotefix/>.