[Top][All Lists]

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

Re: lynx-dev PATCH for ENABLE_RC

From: Doug Kaufman
Subject: Re: lynx-dev PATCH for ENABLE_RC
Date: Sun, 15 Jun 2003 13:19:49 -0700 (PDT)

On Sun, 15 Jun 2003, Thomas Dickey wrote:

> On Sat, Jun 14, 2003 at 10:24:20PM -0700, Doug Kaufman wrote:
> > The following patch is submitted for discussion, rather than to fix
> > a bug. The question I would like to bring up is what should be the
> > appropriate default values for ENABLE_RC. When the "ENABLE_RC" section
> > ...
> There's two issues here:
>       a) do the comments in lynx.cfg for ENABLE_RC reflect the actual
>          defaults program behavior.
>       b) have any of the defaults been altered without discussion.
> I think the answer is that (a) perhaps, (b) not that I'm aware of.   The
> reason for any differences, whether a/b is that originally lynx.cfg and
> .lynxrc used different names for the same item.  I thought I'd found/merged
> all of those with 2.8.4, but as you see from the change log, 1-2 were noticed
> after that point.  (I'll study your patch - thanks).

I went back and looked at some of my archived lynx installations. There
are actually two other questions besides those you mention above:
        c) do the comments in the OPTIONS page reflect the actual
        default program behavior?

        d) Now that ENABLE_RC is configurable, should the default behavior be

I believe that the answer to question a) is "yes". The values for
ENABLE_RC seem to reflect the coding in LYrcFile.c

I had thought that the answer to b) was "yes", but on further review of
the archived files, I see that it has not.

The answer to question c) is "no". The comments in the OPTIONS page do
not reflect the default behavior. Specifically, the comments there were
changed between 2.8.4dev.20 and 2.8.4dev.21 to state that the bookmarks
file and execution links settings would not be saved, but it appears
that the default behavior was not altered at that time; only the
comments were.

I believe that question d) is the crux of the matter. Now that ENABLE_RC
is configurable, what is the most appropriate set of defaults? I would
hold that the main purpose of the lynxrc file is to permanently save
changes made from the OPTIONS page. There are currently multiple other
settings saved there which can only be altered by directly editing the
lynxrc file. Does it make sense to have two different files (lynx.cfg
and the lynxrc file) having settings for the same action, each of which
must be hand edited, with one overriding the other? What is the purpose
of having those settings in lynx.cfg which are automatically overridden
by the settings in the lynxrc file? For example, why even have a setting
for COOKIE_FILE in lynx.cfg (except for an initial setting before a
lynxrc file is saved). If we are to continue this behavior, shouldn't
we put a warning in lynx.cfg for these settings that the values will
likely be overriden by the lynxrc settings. There is currently a warning
for the bookmark file, but not really for the other settings in this
category. I just don't see the point of competing files for the settings
except for those settings we are changing from the OPTIONS page. Is
there a category of user who has access only to the lynxrc file but not
a lynx.cfg file? If so, it might be reasonable to have those options
in the lynxrc file, but now that ENABLE_RC is configurable, whoever
is setting up lynx on that system can enable those options. For other
users, the current system just seems to add confusion.

After review of the above, I would like to retract my recommendation
that the default bookmark file be taken out of lynxrc, especially since
the other bookmarks of a multibookmark setup would still be there. I
would suggest, however, that the "(!)" be removed from the display on
the OPTIONS page so as to correspond to the true default. I still
support my other suggestions for change.
Doug Kaufman
Internet: address@hidden

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

reply via email to

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