Re: lynx-dev Re: disable wording (was: lynx2.8.2dev.20)

[Webmaster Jim]

On Fri, Mar 26, 1999 at 03:38:18PM -0600, Klaus Weide wrote:
> On Fri, 19 Mar 1999, Webmaster Jim wrote:
> > I patterned the "--disable-gopher" et al options after
> > --disable-partial, and after seeing John Bley's recent note about the
> > latter option, I'm rethinking the terms. The disable option is used in
> > at least 2 ways, one to not include the code in the binary, and one to
> > set a default condition.
> The second meaning shouldn't really be done with --{dis,en}able-* at
> all.  It is at odds with the the generic description
>     --disable-FEATURE       do not include FEATURE

Oops. I was working on memory, which falters when you're over 40 :-(

Here's a more awake question (I hope). Enabling DIRED causes it
to be the default. I seem to have mixed up the logic in designing
DISABLE_FINGER so that it's backwards from DIRED. The DIRED flag is:

#define DIRED_SUPPORT 1
while the others are:
#define DISABLE_NEWS 1

Thus, to include DIRED code lines, you do this:
#ifdef DIRED_SUPPORT
       "dired_support" ,
while to exclude FINGER, you do this:
#ifndef DISABLE_FINGER
           no_goto_finger = !(CAN_ANONYMOUS_GOTO_FINGER);

While I got the logic to work properly, it's now clear that the
implementation is confusing. Should the "exclude" modules be recast to
be "support" modules along the same lines as the DIRED support?

++++++++++++++++++++++++++++
Marvin the Paranoid Android.