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

Re: menu_context question



 On Thursday, September 7, 2006 at 11:22:16 -0700, Charles Killian wrote:

> I prefer when paging to have context lines

    Me too. It seems a relatively important ergonomic feature, and a
legitimate wish. Sufficiently important to justify yet another
configuration variable, IMHO.


    [explicit paging]
> if I see 1-34c(k) for some variable k, and I next-page, I would like
> to see 30-63c(k+29).

    That's what we called "fixed altitude" cursor. Tamo implemented this
scheme in one of the prototypes: It was very nice, and I liked it well.
But then the "border pushes cursor" scheme is also nice, more consistent
with other features, consistent with Mutt's historic behaviour, and
requires less code. And such minor cosmetic preference didn't justify to
implement both schemes and add YACV.

    Tamo: What about extracting a "fixed_altitude_indicator" feature
patch out of patch-1.5.9.tamo.menu_pageup.4?


    [noscroll implicit paging]
> If I see 1-34c34, and next-entry, I would like to see 30-63c35

    As it is contrary to the margin concept, I suppose that the way to
go there would be with $margin=0 and $menu_jump_context=5. Problem: IIRC
$menu_jump_context doesn't act for implicit page jumps. And I'm not sure
if it would be extendable without creating unwanted interactions with
the margin setting, and maybe also with $menu_scroll=yes.

    An aspect of the problem is that, with both a cursor margin and a
paging context available, it is expected that the values will not be
equal. I mean users typicaly may want any $margin value, 0, 5-10, or
even 999 to center cursor. While $jump_context would probably most
naturally be only 0 or 1, rarely more (too much context is against the
page jump concept ;-).


> some way to set-apart the margin so that I would visually be ready for
> the page jump when scrolling. For example, if I could use, say ~M to
> match messages in the margin of the current viewport, then I could
> either use colors to shade the margin, or index_format to otherwise
> mark messages in the margin.

    Hum... I think visible margins is not a bad idea, but...

 - Once accustomed to a given margin setting, the user less needs a
visual hint.
 - Personally as a user I don't need nor want it at all.
 - Crafting a new ~M pattern for that is overkill. IMHO: Bloat. Out of
question.
 - Coloring index lines inside the margin would overrule color index,
which is most probably unwanted.

    I think we'd need to imagine and agree on a non intrusive but clear
visual hint, which might prove difficult. And with a simple
configuration, just on/off boolean, or nothing. The feature isn't worth
much complexity.


Bye!    Alain.
-- 
When you want to reply to a mailing list, please avoid doing so with
iPlanet Messenger Express. This lacks necessary references and breaks threads.