Re: lynx-dev lynx2.8.2dev.26

[David Combs]

On Wed, May 05, 1999 at 09:01:48PM -0400, address@hidden wrote:
> 1999-05-05 (2.8.2dev.26 - 2.8.2pre.1)
> * remove some weird cruft from HTAAUtil.h (yeah, "/home2/luotonen" is a good
>   default path) (John Bley)
> * correct a buffer overflow in LYDownload.c (reported by John Bley) -TD
> * 8bit attribute values are now translated in psrc view (reported by LP) -VH
...


Proposal for these notices of changes:

Somehow distinguish "internal bug fixes" from "new or changed features"
that the USER needs to know, that eg would end up in the manual.

I note the use of the "*" as an item-marker in the current (above)
format.  Perhaps "**" for those that would (should) end up in
the manual...

---

You know, what would REALLY be nice for the manual is some kind
of "hidden" date/version-num construct around changes in the manual.

Amazingly, I don't know html -- but I assume (??) that there is
some kind of "conditional text" facility in html?  That those
who wanted this version-info could activate if they wanted
to.

So that they (we) could scan just the NEW stuff, new since the
LAST time we chose to look at the manual.

If no such conditional feature exists, then surely html has
comments (???); then the new stuff could be wrapped in
"begin comment NEW FEATURE ver xyz date 11mar98" (matched
with identical "end comment ...") --

, then we can, by hand, or by program (perl?, sed?), produce just
those change-regions of html, and either read it straight 
as html, or wrap it somehow and run it through lynx to
see it "nice".

----

Of course, best of all would be change-bars, but I can't
imagine that html would have those.  With dates/versions.

-----


Another idea would be to have the "source" manual be filled
with all kind of notes, dates, etc, and then run it through
some filter to produce the "standard" manual (also html, of
course).  Both would be available to the user.

---

Just more ideas that involve work on someone else's part.

     :-)

David