lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev LYNX: more pleas for the L-page addrs


From: mattack
Subject: Re: lynx-dev LYNX: more pleas for the L-page addrs
Date: Sun, 17 Jan 1999 16:37:58 -0800 (PST)

On Sun, 17 Jan 1999, Klaus Weide wrote:
>> [LINK] for unvisited links, and
>> {LINK} for visited links  or maybe
>> (LINK) for visited links.
>
>I assume with LINK you mean the actual link number.  Note that not
>everyone has link numbering on.

Link number and/or link text.

>It seems you are talking about modifying the display of the actual document,
>not just the LIST page.  Right?  Below I assume that.

Yes, that's what I was talking about..  

>1) We don't have _reliable_ information on which documents have already been
>   visited in the quickly accessible form used currently in the LIST-
>   generating code.  (The HTParentAnchors where the title is stored tend
>   to be uncached from memory after a while).  We have the Visited Links
>   list info, but that would be much slower to search through for each
>   link.
>2) The Visited Links info is only per-session anyway.  If you seriously
>   want to use this type of hints, you probably also want to have something
>   more permanent.

Hmm, I think I keep my cache pretty low on GUI browsers so don't tend to
run into links I've used from previous sessions.. (as in links colored 
like I've been through them).  I realize that's just one data point.

But anyway, even simply per-session visited links 'live' would be useful.

The most common case of this is to partially alleviate the problem that 
even IE has a new solution for -- when you have one page and you want to 
successively go to links from a page and go back to the originating page.
(IE has something called a page holder or somesuch..)

If Lynx showed me the visited links with a different character surrounding
them, it would prevent me from taking the same link again accidentally.

>3) Changing the appearance of link numbers at the time the rendered text
>   structure is built could only rely on information at the point in time
>   when the text is parsed.  As soon as a link is followed, the choice
>   of parentheses could be outdated.  When you go back (PREV_DOC), you
>   you would see a misleading hint.  Any attempt to remedy this would
>   involve either re-rendering the document with the link completely
>   (an all-around bad idea, especially since we don't yet have a "raw bytes"
>   cache, so a new network request would be needed), or messing with the
>   already-rendered text structure (theoretically possible, but a new kind
>   of hack nobody has tried yet).

Darn, you're right.  Jeez, so the completely rendered text is what's kept
around?  Darn.. If it kept the source around and re-parsed it, this
would be fixable.

Darn..  Guess this isn't really doable at this point in time.

>4) If you PRINT a document, you would improperly keep those hints although
>   they should be only ephemeral.  Also, what should happen for -dump?

I don't see how -dump comes into the issue.  If you have visited them in that
session, show them that way, if not, don't.    I use -dump to get the
StudioBriefing report from imdb mailed to me in a cron session daily, but
don't use it other than that.  So maybe I don't know exactly what -dump does
and why this is relevant.

reply via email to

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