[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev flickering upon first bookmark display

From: David Combs
Subject: Re: lynx-dev flickering upon first bookmark display
Date: Wed, 8 Dec 1999 22:10:34 -0800

Maybe someone who hacks that part of the code could stuff
some of this stuff in there as doc, or insert this into
a file and then add a pointer to the file, as a comment.

I wouldn't rely on the archive -- it must be HUGE by 
now -- you want something that you can include with
the .tar.gz or a doc subdirectory.

This is just a quick idea from me, probably all wet,
but once in a while one does see things go by that
sure LOOK like good historical stuff, explanation,
that is held only in some people's heads -- and when
and if they stop working on lynx, that's gone too.

(Heck, maybe there already is such a set of this
doc -- I've never looked at the source, etc, but
just USE lynx (that someone else installed on netcom)).

Anyway ...

On Wed, Dec 08, 1999 at 02:41:27PM -0600, Klaus Weide wrote:
> On Wed, 8 Dec 1999, Leonid Pauzner wrote:
> > 7-Dec-99 19:02 Klaus Weide wrote:
> > > On Sun, 5 Dec 1999 address@hidden wrote:
> > 
> > >> I start up with my bookmark file as my start page, and I have 
> > >> multi-bookmarks
> > >> turned on.
> > >>
> > >> The bookmark file draws, THEN the whole screen redraws with:
> > >> Description: Default Bookmark File
> > >>    Filepath: lynx_bookmarks.html
> > > Well the double-drawing is only there with partial display on.
> > 
> > Hmm, that seems to be a chunk of code in mainloop under the case
> > NORMAL: when the first document loaded, it checks the page title
> > and than search a list of Multi-bookmarks for newdoc.address,
> > than goto try_again if the file recornized as a bookmark one.
> > 
> > Is it reliable to relay on title?
> No, of course not, but lynx is doing it in several places.
> But this is not one of them: the check for the title is only one
> of several conditions that are ANDed.
> > If we can live without the title here
> > (which could not be found without loading the document), we could
> > probably move this chunk away from the case NORMAL on top of mainloop
> > near 'bookmark_start' staff to avoid double loading in this particular
> > case. Will it be a bug fix or lost the feature?
> It makes sense to have this extra check before treating the file as a
> bookmark file IMO.
> Even mattack says it's only a minor annoyance to him (or words to that
> effect); it happens only once in a session; it's not worth changing the
> program structure for, IMO.
> He isn't actually annoyned with Lynx's roundabout way to detect a
> bookmark file; he is only annoyned with the way it is becoming
> visible.   But that happens only with -partial, and arguably, by
> using -partial and starting lynx this way he's asking for it.
> >                     /*
> >                      *  If it's the first file and we're interactive,
> >                      *  check whether it's a bookmark file which was
> >                      *  not accessed via the -book switch. - FM
> >                      */
> The "standard" way to access a bookmark file (and have it recognized
> as such) is via bookmark-specific commands: 'v' as a key, or '-book'
> on the command line.  If lynx sometimes recognizes a bookmark file
> even if you don't do that, it is because of code additions that Fote
> made because people kept asking for it.  But those work only in some
> cases anyway (here: if the file in question is the "first file").
> The canonical way to *start* with a bookmark file (and have it
> recognized as such) is -book.  That hasn't ever been properly
> generalized for starting *directly* with such a file.  But you can
> still start with -book if multi-bookmarks is on - you just have to
> answer a prompt then and select a bookmark with a letter (or press
> return for default).
> Finally, if someone just want to start lynx with that file and just
> doesn't care for it being recognized as a bookmark file and being
> treated specially in some ways - there's a trick possible to prevent
> the special first_file recognition.  Just use some unusual form for
> the starfile that doesn't get recognized; for example, instead of
>    lynx ~/lynx_bookmarks.html
> use
>    lynx ~/%6Cynx_bookmarks.html
>    Klaus

reply via email to

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