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

[Klaus Weide]

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