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

[Klaus Weide]

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

> The flags in dev19 are included below.
> 
>   Two flags (partial and dired) say use or enable in the definition,
> while the others say disable. The hint in all cases says "default: on",
> so I'm staying with my original thought on the phrasing.
> 
>   On the other hand, perhaps we need to differentiate options that
> include code versus options that set defaults:
> 
>  (default: compiled in)
>  (default: not compiled in)
>  (default: switched on)
>  (default: switched off)

The last two shouldn't apply to any --disable-* option.  If being switched
on is only a default that can be overridden at runtime, the FEATURE
obviously is "included".

Btw., in the name of fitting as much as possible on 80 column lines, can't
we just get rid of the "default: " prefix completely?   The trailing
parentheses always have the default, it should be enough to state that in
one place.  Like

   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no,
                                                   parentheses list defaults)
   --disable-echo          test: display "compiling" commands (enabled)
   --disable-trace         disable logic for trace code (enabled)
   .....

Or completely get rid of listing the default for each option...

> Dev19+ options:
> 
>   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
>   --disable-echo          test: display "compiling" commands (default: on)
>   --disable-trace         disable logic for trace code (default: on)
>   --disable-full-paths    control whether full utility pathnames are used 
> (default: on)
>   --disable-config-info   disable browsable configuration-info (default: on)
>   --disable-forms-options disable experimental forms-based options (default: 
> on)
>   --disable-menu-options  disable old-style option menu (default: on)
>   --disable-extended-dtd  disable extended HTML DTD logic (default: on)

Has anyone ever used this one, does it work?  It only eliminates some of the
the SortaSGML code, but doesn't disable it completely, I don't think it is
very useful and have never tested it.  ^V switching should still work,
not sure what it effectively does in SortaSGML mode.

>   --disable-partial       use partial-display logic (default: on)
>   --disable-gopher  disable GOPHER logic (default: on)
>   --disable-finger  disable FINGER logic (default: on)
>   --disable-news  disable NEWS logic (default: on)
>   --disable-dired          enable optional directory-editor, DirEd (default: 
> on)
>   --disable-dired-archive  disable dearchiving commands (default: on)
>   --disable-dired-override disable private keymaps (default: on)
>   --disable-dired-permit  disable chmod/attrib commands (default: on)
>   --disable-dired-xpermit disable chmod/attrib commands (default: on)
>   --disable-dired-tar     disable "tar" command (default: on)
>   --disable-dired-uudecode disable "uudecode" command (default: on)
>   --disable-dired-zip     disable "zip", "unzip"  commands (default: on)
>   --disable-dired-gzip    disable "gzip", "gunzip" commands (default: on)
>   --disable-long-list     disable long "ls -l" directory listings (default: 
> on)
>   --disable-parent-dir-refs

A quick look through the above list doesn't reveal any option that is used
in "the second meaning", although I didn't check the details; is there one?
They all seem to really disable code, not just set a default for some
variable(s) that can be changed at runtime.

    Klaus