Re: lynx-dev Forms based options (patch)

[Mike Castle]

Amazingly enough Leonid Pauzner said:
> > +           /*
> > +            * FIXME: I have no clue if I got this right.  Since this is
> > +            * forms based, we should probably flag that we may have
> > +            * changed something here, then when we're done, check to see
> > +            * if the user also changed RAW mode.  If they did, take what
> > +            * they set, even if it doesn't make sense.  Otherwise, use
> > +            * what we calculate here.
> > +            */
> 
> Mike, your patch at this point differs from plain 'dev18' behavior.
> It comes from history that RawMode works too complicated: it uses
> ~~5 functions from LYCharSets.c.
> Not beeng involved in general code rewriting
> (we may got CJK support broken, few of us can test it...)
> we need to follow existing rules.
> 
> Brefly speaking, if we change assume_char_set
> so that assume_char_set == display_char_set
> we should get LYRawMode automatically ON,
> but this is not appears from your code in fact.

Yes.  This code is quite convoluted here.
Part of the problem is, every field in the form is getting processed, even
if the user didn't change it.  So if the form is pre-filled with raw mode
off, and they don't explicitly change it, it will stay raw mode off.

The original options implementation will arbitrarily set raw mode in several
places, so even though the user may never have explicitly changed it,
changing another field will effect it.  Until we get javascript support
(notice I'm speaking confidently here about *that* ;-), it will be
impossible to accomplish the same thing.

What I think needs to be done is set a bunch of flags like
feature_x_changed_raw_mode.  Then when done processing the form, check all
the flags, and depending on what got set/unset, and if the user did not
explicitly change rawmode themselves (really, how can one tell?), then
follow the old logic.

Perhaps the raw mode form entry (and that's form entry ONLY), should be
tri-state:  Force on, Force off, Suggested (X)  where X would be filled
with ON or OFF.  Currently, if you change some other settings, the user has
to go out of their way to change raw mode if they want to.  So, the
precedence of the user requiring extra effort on this part is already
there.  And I suspect most will stay with the Suggested option.

> Another note: we need to add some logic
> for reloading with HTuncache_current_document()
> to take options changes in effect for current document.

Correct.  Like I said in my original post, this was handled in the original
code upon the return from the modal options screen.  I'm not familiar with
the function you mentioned here, so I'll have to check that out.

> --- old\lyoption.c      Thu Jul 30 16:00:54 1998
> +++ lyoption.c  Fri Jul 31 01:00:40 1998
> @@ -23,6 +23,9 @@
>  #include <LYLeaks.h>
> 
>  #define FREE(x) if (x) {free(x); x = NULL;}
> +BOOLEAN term_options;

I was kind of holding off doing this for a bit.  I currently don't mind
having both sets of code compiled right now, and I wanted to get most other
things working before I started compiling without the old code.  For
instance, I have no clue yet what "term_options" does.  You obviously had
to move it outside of the ifdef for linking reasons, yet I don't touch it
at all in my code (and probably should be!).  However, now I guess I'll
delve into it.  :->

Thanks for the feed back!

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