Re: lynx-dev RE: "remove the r command"

[Serge MUNHOVEN]

On Sun, Dec 13, 1998 at 07:04:17PM -0500, Philip Webb wrote:
 >  981212 Larry Virden wrote: 
 >  > The problem isn't the bookmark file, which is indeed just html.
 >  > The problem is once it's read in the html,
 >  > Lynx doesn't know anything about the original file.
 >  > when the user types 'r', it doesn't know the _real_ line number to delete.
 >  > It probably makes assumptions
 >  > based on the number of lines it outputs before the links begin,
 >  > as well as the number of the link, which it does know.
 >   
 >  my proposal therefore is that Lynx should read the bookmark file HTML
 >  without rendering it, when given the command `r'; it should then
 >  count the number of anchors to determine which piece of HTML to remove.
 >  after all, it HAS to edit the HTML, not the rendered version
 >  in order to remove the bookmark from the persistent bookmark file.
 >  is this difficult?  which piece(s) of Lynx source should i examine?
 >  
IMHO the underlying problem might be a bit more general. I've got a few
bookmark-like files which I happen to update using lynx's (E)dit
functionnality. A simple annoyance that has been on my investigation list for
quite some time is the line number provided by lynx to the editor.
Depending on the HTML, it may indeed be of by a lot more than one (in my case
probably due to the heavy usage of comments). One idea was to study in detail
what the rendered format looks like and see if it is possible to hide at
the beginning or end of each rendered line the corresponding true line number
in the raw HTML.

As far as only the bookmark files are concerned : there seems to be no
ambiguity as to the displayed link intended when "r" is hit. But Lynx would
only be able to give a valid confirmation prompt after a dry run of the actual
removal on the file.

How about inserting a hint for lynx ? Something like :
<LI><!--LYNXBOOKMARK--><a href="http://any.where";>Many lines</a>
If it weren't to keep the HTML valid for any browser this could be more
compact. You will still be able to handedit your bookmarks and, yes I agree,
to easily mess them up. Thinking about it: why not simply count the <LI> list
items and declare that each one is considered as a single indivisible
bookmark ?

Finally "bells an whistles" solution : have a hashkey for each bookmark in the
source and refuse to remove mismatches (safe, difficult to implement, easily
broken ...)

Just a few thoughts,

 - Serge

-- 
 Serge Munhoven                              Internet: address@hidden