[Top][All Lists]

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

Re: lynx-dev LYNXCFG:, LYNXCOMPILEOPTS: (was: something wrong with LYNXK

From: Klaus Weide
Subject: Re: lynx-dev LYNXCFG:, LYNXCOMPILEOPTS: (was: something wrong with LYNXKEYMAP)
Date: Thu, 18 Nov 1999 03:50:23 -0600 (CST)

On Thu, 18 Nov 1999, Henry Nelson wrote:

> > I don't agree with discouraging use of the old-style menu completely
> > (like Henry seems to suggest), though.  What with the bugs that are
> Actually I'm more devious than that. :)  Not having all that clutter on
> there actually would ENCOURAGE me to use the "old-style" menu.  I really
> find LYNXCFG:/ superfluous.  

You should be happy then that there's little chance it will ever be added
to the old-style Options screen. :)

> I know basically what is in lynx.cfg
> anyway, and if I want to view it, I would prefer to view it as a text
> file (g => ./.lynx/lynx.cfg) since then I can see the comments and notes
> to myself that I've put in there.

I don't really know why we have to have all this stuff...
I am just trying to answer some of your questions here (as the person
who added -restriction flags for these features, after their existence
was a given), but don't hold me responsible for the existence of the
features (or their incomplete configure-time-turnoffability).

> > > IMHO, for forms-based menu one could move LYNXCOMPILEOPTS:/ from
> > > the =)information page down to the O)ptions menu (as a separate link
> > > or a reference from the LYNXCFG:/ in turn. Does it have any sence to
> > > have 'lynxcfg_info' disabled but 'compileopts_info' enabled the same
> Was there a way to disable 'lynxcfg_info'?  I know we have '--disable-
> config-info', thank goodness!, but what is the option to disable 'lynxcfg
> _info'?

There is none afaik, but there is one to disable *part of it* - the "extended"
part - it is included in the following:

> I wonder if the description of the option is correct:
>   --disable-config-info                 (define NO_CONFIG_INFO)
>         Use this option to disable extended browsable configuration 
> information
>         (a screen that shows the result of the configuration script, as well
>         as extended lynx.cfg viewing with a pointer to the lynx.cfg file and
>         additional functionality).
> The description suggests to me anyway that there will be NO "extended
> lynx.cfg viewing", yet with this option set, I still have the "your
> lynx.cfg" link on the =)nformation Page, the very page where I don't
> want it.  Bug?

A question of definitions...  that's not "extended lynx.cfg viewing", that's
just "basic" lynx.cfg info viewing (which is still an extension and not at
all the same as visiting your lynx.cfg file with a "file:" URL).

IIRC "extended" implies that LYNXCFG:/ shows from which file an option
comes (in case of, possibly nested, included files), and that there is
a LYNXCFG://reload link.

> I see nothing "extended" about the viewing of lynx.cfg through LYNXCFG:/;
> it's an abreviation (no comments), not something extra.  

You probably have already excluded the "extended"ness at configure time.

> To get the same
> result as LYNXCFG:/, all I need is a sed one-liner in a PRINTER or
> DOWNLOADER.  Lynx could just as well have file://localhost/path/to/lynx.cfg
> since it needed it to start up with anyway (protection against /dev/null of
> course).

That is more true if you have disabled the "extended" features.  Even then
LYNXCFG:/ doesn't show the contents of just one file, but the synthesis
of the main lynx.cfg and all included files.  Of course, if you don't use
INCLUDE, this difference doesn't matter.

What's so special about /dev/null?

> > 'lynxcfg_info' may show info specific to the machine lynx is running on
>                                ^^^^^^^^^^^^^^^^^^^^^^^
> Sometimes.  But if it is a private lynx.cfg, then it will be specific to
> that user, or perhaps even specific to some purpose a user has, i.e.,
> multiple lynx.cfg files.

You're right.  My point was that compileopts_info is more generic kind of
info than lynxcfg_info (and normally less sensitive), you are further
confirming that point.


reply via email to

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