Re: lynx-dev 'reloading' lynx.cfg (was: options (more, please))

[David Combs]

On Fri, Jul 16, 1999 at 06:24:18AM -0500, Klaus Weide wrote:
> On Thu, 15 Jul 1999, Michael Warner wrote:
> > On or about 15 Jul, 1999, David Combs
> > <address@hidden> wrote:
> > > The almost-worst situation is having to change the .cfg.
> > > 
> > > Slightly less bad is by command-line arg, meaning that
> > > you have to still rerun an entire lynx to try it.
> > 
> > I think you've got these two reversed, since the redoubtable Mr
> > Pausner (I think) added re-sourcing lynx.cfg on-the-fly a while
> > ago.  I use it quite a bit, and am very grateful to have it.
> > 

QUESTION and NEED: How does a long-time user of lynx FIND OUT
about these new features?

I haven't checked, but such changes probably are NOT yet in
the manual.  (True, false?)

And, if they are, how to find them?  Via diff'ing two versions
of the (re-"filled"!) manual?  Impossible, of course.

SUGGESTION: every change in features, etc, to the manual be
preceeded by a DATE, eg "[17jul99]", then we can grep for
eg "[a-zA-Z]99\>" (or better yet, and far easier, via 
M-x Occur in emacs), and scan over
that list, going to places not-yet-seen (as per the date).

----

The "changes" we all see posted to this list are 99.9% re
BUG FIXES.  Perhaps the special string "xxFEATURE:" or 
"^NEWFEATURE" (uppercase, plus maybe "--------" following it
to the right, blank line before and after, making it easier to
see), would help for that .1% that affects (effects?) our USAGE
of lynx.

---

Of course, some ONE person could do that FOR us all, duplicating
that .1% into a SECOND "featureCHANGES" file -- that way, the
work would get done ONCE, instead of HUNDREDS of times, once
per reader.

---

I think the date-idea should be done, regardless of hoped-for
changes to the changes-file.  We have a huge number of users
of lynx, probably only .1% of them being on this list.

THOSE people, the 99.9%, need some way to see NOT just a short
note that "xyz has been added", but the entire doc on it, with examples,
etc.  Adding that to the manual, with date, would make seeing it much
easier.

---

ALSO: in the table of contents, or separately, like a table of figures,
a table of changes (dated).

---

Maybe a "rule" (Dickey-enforced) that no new feature goes
into the released-version UNLESS documented for users?

---

Some might say, "why the Date?  Why not the version number?"

Both are useful.  for those who get a new version presto-quicko,
the date is best: most understandable.

For those who get a version only months or years "late", then
the version MIGHT be best.  (The date, if printed along with
the version number of the version, eg at the beginning of the
manual, eg "this is manual for version xyz, of <date>", makes
the date usable for that too.)

Also, the date is just plain easier for the eye/brain to
parse; we see them every day (dates), whereas the version
number is hard to pick out, especially the diff from one
version number to the next, at the end of a long string
of numbers (major releases done only every so often).  And if dates are
added to the manual AS the features are added, ie BETWEEN major
releases, that eye/brain combination can EASILY scan and understand,
almost unconsciously, the "betweenness" of two dates (we do it
many times every day).




Any comments?

David