lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev pre.10 : Options Form/Menu


From: Nelson Henry Eric
Subject: Re: lynx-dev pre.10 : Options Form/Menu
Date: Tue, 13 Oct 1998 09:51:26 +0900 (JST)

> > Would something like the following be acceptable:
> >   --disable-old-options-menu  -- snip --
> > I'm fighting to keep this option, until 1) it is proven
> > that the new forms-based method is absolutely safe for anonymous mode
> 
> surely you don't need this option: no-one does.

Okay, I don't "need" it.  But, _it's already there_, and I WANT it.
What's wrong with that?  I can't see that taking the option out is
any easier than modifying it's documentation.  Using it you get a
savings of 22Kb+ on each file system Lynx is installed.
                    ~~~~
> > 2) a key is implemented to go to the previous field -- snip --
> or goto Top Of Page & navigate down again?  or DK's suggestions?

Actually, I apologize since I forgot that I had found a way out of this.
Besides the poor telnet emulation, there was a conflict with Atok6, the
Japanese FEP (front end processor) we use; it uses the arrow keys for
actions on the string being processed.

> but the configure option is already obsolete.

It is NOT obsolete, and will not become obsolete until the old code
is removed.  This has to do with the logic Tom used for the option.
The option *removes* the OLD code.  It does NOT enable the new code.
The new forms option menu is compiled in with/without the compile option.
It does exactly what you are anxious to get done.  Why don't you take
the reward that is due to you for using experimantal code?  Why keep
the old code if you don't plan to use it?  (I do want to keep the old
code a bit longer until I've satisfied myself that the forms code is
for sure the way to go.  Even the author of the code had reservations
about it's security.)

__Henry

reply via email to

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