Re: lynx-dev nothing changes/no way to save changes on O)ption page

[Klaus Weide]

On Fri, 29 Oct 1999, Henry Nelson wrote:

> > be quiet.  I admit it is mostly because I feel that folloing through
> > with your proposal would inconvenience *me*.  (Still I think I am not
> 
> Could you be more explicit?  Are you speaking as a user or as a developer
> who needs both compiled in in order to toggle quickly between behaviors
> for comparison/debugging?  IOW, how exactly are you inconvenienced by
> having only one or the other available (can't use both at the same time)?

I'm not sure I can keep the two roles (U or D) apart.

I usually want the old-style menu for quick switching (most often for
different Display Character Sets).  But some options are already only
available on the new forms page, and that's going to increase.  So
somtimes I want to use that one.  The inconvenience is having to
compile (and keep around) two binaries for the same version.

So in some lynx sessions I want to change d.c.s. often, in others
"Cookies", and I would use different -forms_options for the two.

> I'd like to continue the discussion about the present situation, and how
> it might be made simpler.
> 
> I think another viable option, and better than the present situation, would
> be to offer "both" OR "menu only", and drop "forms only."  (Make the forms
> folk suffer!)

I still don't know why anybody should have to suffer!

I don't know why dropping "forms only" would be better.  It just makes
the choices more unsymmetric.

> The following two descriptions of the configure options are offered in
> INSTALLATION: 
> 
>   --disable-forms-options               (define NO_OPTION_FORMS)
>         Disable the forms-based options screen.  (See --disable-menu-options).
>         Please note that a few users with broken curses may have problems with
>         popup forms fields.  The default behaviour is to compile both forms 
> and
>         menu options code with FORMS_OPTIONS switch in lynx.cfg, or
>         -forms_options command-line switch.
> 
>   --disable-menu-options                (define NO_OPTION_MENU)
>         Disable the menu-style options screen.  (See --disable-forms-options).
>         Please note that a few users with broken curses may have problems with
>         popup forms fields.  The default behaviour is to compile both styles
>         options menu code with FORMS_OPTIONS switch in lynx.cfg, or
>         -forms_options command-line switch.
> 
> 1)  Is it easier to have two yes/no options than to have one option like
>     --options=(forms|menu|both)?
> 
> 2)  (I've asked about this before, but) why the exact same sentence "Please
>     note that a few users with broken curses may have problems with popup
>     forms fields."?  I think the sentence should only be in the description
>     for the option that may cause problems.  Without careful reading, it
>     might be taken as a warning not to compile in either of them so as to
>     avoid popping up problems, i.e., define BOTH --disable-forms-options
>     AND --disable-menu-options (= no options of any kind).
> 
> 3)  The last sentence of both descriptions is not crystal-clear to me.
>     (Don't ask me to rewrite it since I am not a proponent of that default
>     behavior :)

There may be some cut-and-paste editing errors.  It's definitely
not very clear.  We should come up with better text (but the text depends
on whether the two configure flags can be combined).

I agree with your other points: --options=(forms|menu|both) [add none :)]
would be nicer.  It's up to Tom though.  I don't know the details how
such a thing would be named, probably not just "--options".
Full agreement on 2).

Btw. "menu" (as the alternative to "forms") is also quite confusing
(that's not new) - after all the Forms Options Page calls itself
"Options Menu" in the title and header!  Some better terminology would
be, umm, better, any ideas?


Btw going back to the origin of this thread (subject line) thanks
for confirming that the disabling worked - since you couldn't find
a way to submit that's a success, in some sense. :)

   Klaus