Re: lynx-dev Keys with partial

[Klaus Weide]

On Thu, 5 Aug 1999, Ilya Zakharevich wrote:

> >     * From: Klaus Weide <address@hidden>
> >     * Date: Wed, 4 Aug 1999 23:49:54 -0500 (CDT)

> >On Thu, 5 Aug 1999, Ilya Zakharevich wrote:
> >
> >> What is the logic behind nost navigation keys not working with partial
> >> display set?  Most importantly, arrow keys, but mouse would be nice as
> >> well.
> >
> >So try to do it, good luck.
> >
> >Many navigation keys don't make sense in a state where there is no
> >notion of "current link".
> 
> This just restates my question: *why* there is no notion of "current"
> link with "partial"?

It *is* a different question now.

> Is it that nobody yet implemented this logic?

You can look at the code.  Since you have submitted patches before,
you are obviously capable of understanding some of it; and if it is
too confusing, or you don't know where to start looking for this
specific topic, ask concrete questions.  Find how the navigation keys
that *are* recognized during partial display are handled, and think of
how you would extend that to handle more keys.  Find how the notion of
"current" link during normal display is implemented, and think of how
you would extend this to the partial display case.  It doesn't look
trivial to me.  You may come to different conclusions.

The way partial display is implemented now, without a notion of
"current link", but with a notion of "current line" (the first visible
line on screen) during partial display, already made it necessary to
keep track of that "current line" in some non-trivial manner that I
haven't yet completely understood (cf. Newline_partial vs. mainloop's
Newline; Leonid should understand all the details).  It also made it
necessary to make changes to GridText.c's HText_trimHightext and
display_line to get anchor text displayed correctly.  No wonder, since
the display routines, up to that point, could always assume to only be
called for text and anchor structures in a stable, "finished" state.
All this took quite a while to get right.  This alone may explain why
nobody has been too eager to introduce the notion of current link,
with highlighting and navigation etc., during partial display.

But maybe I'm all wrong, and it *is* trivial; if you think so, it's
up to you to try.

> Given this, I see no reason for a separate "switch" in LyMainLoop.c
> (sp?).

But there already *is* a separate switch, and it's not in LYMainLoop.c
but in HTCheckForInterrupt in LYUtils.c.  That's the place from where
key actions during partial display are controlled.  [That's clearly
not the place where this kind of thing belongs IMO, but it's the way
things are currently done.  But maybe it's good that "MO" doesn't
count too much, if it did there probably would be no partial-display-
with-navigation at all...]

   Klaus