[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.
Re: lynx-dev LYNX: more pleas for the L-page addrs, David Combs, 1999/01/18
Re: lynx-dev LYNX: more pleas for the L-page addrs, David Combs, 1999/01/18
Re: lynx-dev LYNX: more pleas for the L-page addrs, David Combs, 1999/01/18
Re: lynx-dev LYNX: more pleas for the L-page addrs, Bela Lubkin, 1999/01/18
Re: lynx-dev LYNX: more pleas for the L-page addrs, Lloyd G. Rasmussen, 1999/01/19
Re: lynx-dev LYNX: more pleas for the L-page addrs, David Combs, 1999/01/19