Some problems I know of:
(I'm behind a few versions, but I haven't seen anything to address
these. Some are old, problems, some new)
1) Some command line options don't get handled correctly when give
values (whether by on/off or by adding +/-):
-show_color, -popup, -raw
Try all combinations of saved setting (.lynxrc) with presence/absense
of command line flag with/without value:
.lynxrc command line flag effect
--------------- ----------------- ----------
show_cursor=off (none) off
show_cursor=on (none) on
show_cursor=off -show_cursor on
show_cursor=on -show_cursor off
show_cursor=off -show_cursor=on off, ERROR
show_cursor=on -show_cursor=on on
show_cursor=off -show_cursor=off on, ERROR
show_cursor=on -show_cursor=off off
.lynxrc command line flag effect
--------------- ----------------- ----------
select_popups=off (none) off
select_popups=on (none) on
select_popups=off -popup on
select_popups=on -popup off
select_popups=off -popup=on off, ERROR
select_popups=on -popup=on on
select_popups=off -popup=off on, ERROR
select_popups=on -popup=off off
IOW, those command line flags always work in their function as
toggles, but the behavior when given an explicit on/off value doesn't
make sense. IMO, the move from simple (valueless) flags to to options
with optional value was never completed, for these two flags (at least).
Similar for -raw:
normal default[*] command line flag effect
----------------- ----------------- ----------
off (none) off
on (none) on
off -raw on
on -raw off
off -raw=on off, ERROR
on -raw=on on
off -raw=off on, ERROR
on -raw=off off
[*] "normal default" is the result of the "Display Character Set"
in combination with "Assumed document character set" (coming
from lynx.cfg and/or .lynxrc (or -assume_charset flag).
Tested only with non-CJK for both; then
d.c.s == assumed c.s. -> on
d.c.s != assumed c.s. -> off
I.e., although the implementation logic for -raw is more complicated
than for the other two, there's exactly the same pattern.
2) The classification of lynx.cfg options that is used for the
HTML generated from it, i.e. all the ".h1" added to lynx.cfg, is
illogical, unsystematic, and often just plain wrong. Frankly, it
would be better not to do this stuff at all rather than having
the current state. It's rather meaningless, for example all kinds
off things are called "internal behavior" that clearly aren't.
# These settings control internal lynx behavior - the way it interacts with the
# operating system and Internet. Modifying these settings will not change
# the rendition of documents that you browse with lynx, but can change various
# delays and resource utilization.
Completely wrong for many options marked as "internal behavior".
E.g., having the right *_proxy can make all the difference between
being able to use lynx or not - that's a bit more than "change various
delays and resource utilization". There isn't anything "internal"
about it, this is about how to contact _external_ hosts.
"Auxiliary Facilities" is meaningless, unhelpful, artificial.
It doesn't help anyone who is looking for an option.
OK, I haven't looked at it in detail very recently, so something
may have changed. This was my impression when I first looked at
it. Does anyone (other than the author, perhaps) find the lynx.cfg-
generated HTML useful in its current state?
3) Similar (but somewhat less) for the "Options Menu". (I'm only
talking forms-based, here). The categories don't make much sense.
The first, big one is called "Personal Preferences", which is rather
pointless (that's what _all_ menu options are supposed to be, after
all. It groups all kinds of misc. options together, apparently
because nobody found a better place. The order doesn't follow
any obvious logic (I'd expect most important options, like "User
mode", to come first). "Document Layout" - bad name, doesn't seem
to describe most options grouped under it. "Execution links" doesn't
really belong under "File Management".
I'll make a proposal for reorganizin the Options Menu if nobody else
does.
(But, please, sombody else should work on having lynx.cfg
headings make sense.)
Klaus
