Re: lynx-dev 2.8.2dev.21 page count broken?

[Johnny Teveßen]

Bela Lubkin (address@hidden) schrieb:

> There *are* B (4) pages in the document.  But the fragment points to a
> position inside one of those pages, so, although Lynx claims this is
> "page A", it's actually some place inside page A (and covers part of
> page A+1).  This happens because Lynx doesn't force 1:1 alignment
> between document pages and screen pages.

Yes, but you _start_ with this #fragment address. But then you
scroll on up and down pagewise, to the beginning, to the end..
and it's still only 1, 2, and 4. I can see no reason why Lynx
should still remember the #fragment in this respect.

> Go to the URL, then hit ^A or HOME or whatever your keymap uses for the
> Lynx "HOME" action.

You mean "scroll up to the top of the document"?

> Now you are on the true page 1, and can page
> through all 4 pages.

I was not able to produce a "(p3 of 4)" output.

> When you go to a fragment, you don't get a restricted view of the
> document; you get the whole document, with the specified starting
> position (which, in this case, isn't exactly on the start of a page).

Yes, but I assumed that when I go to the top of the document,
the counter would be reset to cover the *whole* document, not
just beginning with the fragment's position (I don't think it
does, though).

> It *might* make sense to give more precise information than now, e.g.:
> 
>   inside p1 of 4    [i.e. end of 1 + beginning of 2]
>   inside p2 of 4
>   last page of 4
> 
> Would that have made more sense?

Me, as a simple user of Lynx, would expect Lynx to draw the whole
document internally into several pages, and then output page
indicators according to the *real* length of the document (since
Lynx can also fold empty lines, you know). This sounds just too
logical to me to understand the current countment.
-- 
J. Teveßen, Germany
PGPkey: http://pgp.lsi.upc.es:11371/pks/lookup?op=get&search=0x5C77B04D