[Top][All Lists]

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

Re: lynx-dev have big patch

From: Mike Castle
Subject: Re: lynx-dev have big patch
Date: Fri, 4 Jun 1999 20:32:46 -0500

On Fri, Jun 04, 1999 at 02:56:46PM -0700, Bela Lubkin wrote:
> Mike Castle wrote:
> > Hit, say for example, ':', then type in an option, say "parser=sortasgml"
> > just like you wold from the command line.
> > 
> > Hmmm... Bela, that could be another option for the configuration table:
> > should changing this option force a reload?
> That's probably at the wrong level.  It isn't the options manager which
> makes that decision, but the renderer (really the document cache
> manager).  

Ah.  I forgot that lynx now has a source cache (I've been busy and not
built anything since 2.8.2dev3).

> It also has to make two different decisions: "force a
> reload?" and "force a re-render?".  For instance, IMAGE_TOGGLE ('*')
> only needs to force a re-render, while changing your preferred language
> might force a reload (re-fetch from server).

Well, I was thinking along the line of the routine that would gets called
with the string "parser=sortasgml" would return an enumerated value.
OPT_SUCCESS_RELOAD, for instance (error could be anything such as unknown 
option to disallowed for security reasons; maybe want to expand OPT_ERROR
to be more specific, but doesn't affect this discussion).

Then, in MainLoop or something, when the function that handles the ':' key
returns, it returns with one of those values, and decides what to do at
that point (I'm not sure where this is handled now).

> These decisions need to be made by the cache manager on a basis of "does
> the copy of this object which I have in cache meet the new criteria?".
> I suppose that the information about which flags might force actions
> *could* be stored in the flags for each option, as a matter of
> convenience.  But they would *belong* to, be managed and observed by,
> the cache management code.

>From reviewing my archives (I guess I need to download the latest source
soon), it looks as if each document maintains a listing of certain options
that, if change, would force a reload or rerender.  If, instead of
hardcoding these into the appropriate functions, the array of options would
instead be walked, and if a certain option is tagged as being able to force
an action, the record it and check it the next time it's about to be
redrawn.  Keep everything in one location.

Actually, probably preprocess the array, and build a list of "Items that
force a redraw" and "Items that force a reload" and just walk those, rather
than the whole array each time (important on saving the options state when
a doc was downloaded and/or rendered, less than when checking what options

       Mike Castle       Life is like a clock:  You can work constantly
  address@hidden  and be right all the time, or not work at all and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

reply via email to

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