[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Screen positioning

From: Thomas Dickey
Subject: Re: [Lynx-dev] Screen positioning
Date: Tue, 29 Mar 2005 11:04:00 -0500 (EST)

On Tue, 29 Mar 2005, Thorsten Glaser wrote:

  ----- The following addresses had permanent fatal errors -----
   (reason: 550 unknown user)

---------- Forwarded message ----------
Date: Tue, 29 Mar 2005 15:13:56 +0000 (UTC)
From: Thorsten Glaser <address@hidden>
To: address@hidden
Cc: Lynx List <address@hidden>
Subject: Re: [Lynx-dev] Screen positioning

address@hidden dixit:

Exit the Info Page with "<--".  Note that you are no longer at the screen
from which you entered the Info Page, but back at "#2".

dev.11i: cannot reproduce, but when I go to source view using "\"
I'm always at the start of the file, not where I was earlier
or where the internal link is.

That's a different problem. Toggling with source view, dev.11h lynx tries to put your cursor on the link that corresponds to where it was in the other view. In the dev.11h fixes, I added some logic to allow this to work in the case where the link wasn't on the first page. That's as good as I'd like because there's not a 1-1 correspondence between the links in both views, and also because the user may be looking at a screen that's not on a link.

The problem that I think is discussed here is one where the position is treated specially when the link begins with a "#". It's (as you see because it didn't work right the first time) rather fragile code to modify since there are several global variables which interact. As part of the source-toggle changes, I reduced some of the clutter that made it hard to follow the code, but haven't done anything for this particular bug yet.

When I move in the source view, I get back with "\" not exactly
to the place where I was in the source, but plusminus a few
screen pages (113x42 xterm here at the moment).

I'm guessing you're seeing the latter case (screen not on a link).  That
only happens to "work" in a very loose sense before/after my changes.
That's because lynx was simply using the line-offset within the previous
view to guess where to put the cursor.  If the rendered and source views
have different line-offsets, the problem is apparent.

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]