[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev LYNX: more pleas for the L-page addrs
From: |
Klaus Weide |
Subject: |
Re: lynx-dev LYNX: more pleas for the L-page addrs |
Date: |
Sun, 17 Jan 1999 16:47:02 -0600 (CST) |
On Sat, 16 Jan 1999 address@hidden wrote:
> >
> >Horrible, horrible, horrible.
> >
> >Why not a leading asterisk or something, to mean "been there
> >already".
>
> I haven't been following this whole discussion and don't understand
> if people are talking about when normally viewing a page, or just at the
> visited links page or something.. (of course you've been everywhere you've
> visited, so I guess I've answered my question)
>
> I was thinking about something like this too..
>
> Why not do something relatively subtle but noticable, like
>
> [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.
> [ ] already encloses both links and checkboxes, so there's no problem with
> confusing (LINK) with a radio button..
It seems you are talking about modifying the display of the actual document,
not just the LIST page. Right? Below I assume that.
> If this is a major hassle or slows something down, it's no big deal.. because
> doing something like this is getting awfully close to "just use a damn
> GUI browser" argument.
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.
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).
4) If you PRINT a document, you would improperly keep those hints although
they should be only ephemeral. Also, what should happen for -dump?
5) Some parts of the code rely on link numbers being surrounded by exactly
'[' and ']' - especially the fickle code for removing link numbers for
"hidden links" after the fact. I wouldn't like to have to make that code
more general.
I guess you can see where I am leaning...
Of course that shouldn't prevent anyone who wants to invest the time from
implementing such a feature.
Klaus
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