[Top][All Lists]

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

Re: lynx-dev Why isn't the show_image option saved?

From: Henry Nelson
Subject: Re: lynx-dev Why isn't the show_image option saved?
Date: Mon, 12 Mar 2001 12:19:06 +0900 (JST)

> > Why a bug report?
> because there's no good reason to treat "show images" differently from
> "verbose images"

More like there's no good reason to even offer "verbose images" when "show
images" is set at "ignored."

So which way are you going to go: make both permanently saved in .lynrc, or
make "verbose images" subordinate to "show images," as seems intuitive?

> (give a reason - a good one - and I'll take that into account).

We've been over this ground before.  My reason is that there is a single-
key toggle for MAKE_LINKS_FOR_ALL_IMAGES, in addition to a compile-time
define and a command-line switch (last I looked some years ago).  All three
related options (LINKS, VERBOSE, PSEUDO-ALTS) and their interaction are
explained well in lynx.cfg, where the preferences may be set permanently.
I see no advantage to the duplication.  In fact, I think the redundancy
only leads to confusion as to how toggles were designed to work in Lynx.
It also means that the detailed directions in lynx.cfg pretty much go to
waste.  Finally, I see a trend in new users to hit 'o'ptions, rather than
'K'eymap.  I see this as a direct outcome of an over-extended Options Menu.

I've long forgotten, so I trust Philip, Leonid or Klaus will supply the
rebuttal to these arguments.

The real solution, if there is one, is that rather than have a string of
interdependent TRUE/FALSE options (which often happens in Lynx because of
"features" tacked on as afterthoughts, e.g., verbose images), there should be
defined, multiple choices set up as tables.  This area was also discussed
heatedly in the past.  It requires programming which no one is willing to do
and no one demands.


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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