lynx-dev
[Top][All Lists]
Advanced

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

LYNX-DEV Re: lynx.cfg changes


From: Klaus Weide
Subject: LYNX-DEV Re: lynx.cfg changes
Date: Wed, 7 May 1997 13:52:37 -0500 (CDT)

On Tue, 6 May 1997, Michael Warner wrote:
> On Tue, 6 May 1997, Philip Webb wrote:
> 
> > one reason i'm slow to grab & test development versions of Lynx is
> > that i have to plough thro'  lynx.cfg  each time for my own settings.
> 
> Just a quick question - I've aliased lynx to include -cfg=~/my.cfg,
> and haven't updated it for a while.  So far that practice doesn't seem
> to have broken anything.

Changes to lynx.cfg are backward compatible (probably always have been).
Meaning that it is not *reuqired* to upgrade lynx.cfg, newer Lynx binaries
will stil work with older (even *quite* old) lynx.cfg files.  But you may
miss the opportunity to configure new things.

You may want to keep an older version of lynx.cfg around (say official
Lynx/2.7.1, or whatever you used when you last personalized your my.cfg)
and periodically diff the latest lynx.cfg from the code against that.
(Or use a more elaborate scheme with scripts.)

> The question: is it safe to assume that CHANGES.new would alert me to
> any need to re-edit lynx.cfg for a new development version?

Although nothing is safe, such changes should always appear there.

Note that new things don't always appear at the top of CHANGES.new.
When I incorporate changes from Fote, I usually use the original
description from his FOTEMODS file, including the date.  So those
may get inserted further down.  This makes it easier to compare various
versions (ther isn't just 2.7.1ac-0.* in the repository) or to compare
CHANGES.new against FOTEMODS.  YMMV.

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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