Re: lynx-dev have big patch

[Mike Castle]

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.
Values might be OPT_ERROR, OPT_SUCCESS, OPT_SUCCESS_RERENDER,
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
changed).

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