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: David Combs
Subject: Re: lynx-dev LYNX: more pleas for the L-page addrs
Date: Mon, 18 Jan 1999 01:03:52 -0800 (PST)

> From address@hidden Sun Jan 17 14:48:14 1999
> Date: Sun, 17 Jan 1999 16:47:02 -0600 (CST)
> From: Klaus Weide <address@hidden>
> 
> <SNIP>
> 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.  

RE this part of item 3):
>    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?

How does THIS 5) code work?  Does it actually scan for square brackets in the
text?  Suppose someone has some title or url or whatever within square brackets;
does that fool lynx?  Clearly, I misunderstand something (as usual).

> 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
> 
> 

Well, surely a pain.  But if this "you have already been there" stuff
is so useful, having it on only the L-page is having it pretty far
away from where you'd want it.


I sure don't know the data structures in lynx, but
I would imagine that each url mentioned had ONE
url-struct, which contained a ptr to a linked
list of the occurrences of that url in the page,
each of those "occurence struct" also having
its own label string, the one for that occurrence
(or is it called a "title"?) -- with a backptr to
that url-struct.

Also, each occurence struct would have pointers
to the char-position of the [ and the ].

The url-struct would have the been-visited bit.

---

Now, what happens when hidden links are suddenly turned on --
oh, at least via the * key, the page is re-rendered,
so all that stuff would be regenerated, no?, so it
should work ok?

---

Easy.  Just a SMOP ("small matter of programming"). (joke)

(pretend it is 1apr99) (yeah, I know it's y2k-bad, but
I will continue using two digits, written as above,
with a 50-yr bias)    :-)

David



reply via email to

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