Re: Should we move 20.x related stuff out of NEWS ?

[Alan Mackenzie]

On Sat, 17 Apr 2004, Juri Linkov wrote:

>Alan Mackenzie <address@hidden> writes:
>> On Thu, 15 Apr 2004, Juri Linkov wrote:
>>>I must say that having news for old releases in one file is very
>>>inconvenient.  For example, isearching it for some newest feature, the
>>>user can't see if the string that isearch displays is in the latest
>>>version or in one of older versions!

>> A beginning user will have this problem.  An experienced user will
>> know to type C-c C-u, or at the very least C-h m to find the
>> appropriate command.

>Surely, the user can type C-c C-u after every isearch result.  The
>problem is only in its inconvenience.  C-c C-u doesn't leave mark at
>previous position, so it's not easy to return to previous position to
>continue isearch.

A bit like C-M-a.  Admitted, that is an inconvenience.  And it remains
irksome, even after having got into the habit of doing C-u <space> before
each C-c C-u.  ;-(

>>>If having too many files is undesirable, then files for only _major_
>>>releases could be created, with the NEWS file containing news for the
>>>latest _minor_ release:

>>>NEWS      -- news for 21.4
>>>NEWS.21   -- news for 21.1, 21.2, 21.3
>>>NEWS.20   -- news for all 20.*

>> I disagree with Juri entirely here.  As a package developer, I'll
>> often want to ask a question like "What's the earliest Emacs version
>> that supports syntax-table text properties?", and a quick "C-h n C-s",
>> followed up with a few "C-c C-u"s finds it easily enough.

>You will not find an answer to your question in the NEWS file if a
>feature was introduced in earlier Emacs versions described in
>ONEWS(\.[1-9])?.

This is true.  But splitting up NEWS wouldn't help for this.  ONEWS is
old indeed (1996?).

>> If NEWS were to be split up as described, I'd have to formulate a grep
>> command.

>The current situation with news spread across multiple files is not
>better.  However, one could write a script similar to
>lib-src/grep-changelog.

One could.  But with NEWS as several files, it is only a moderate hassle
to load them one by one and search through them.  If NEWS were many
files, one would then be needing to write some sort of script, or use
grep, etc.

>> [Aside:  Emacs facilities for searching through several files
>> seem strangely poor.]

>There are M-x multi-occur-by-filename-regexp and `A' in Dired.
>Or what did you mean?

There's nothing like Isearch for several buffers.  It'd be nice to be
able to C-s across several buffers, <del> back again, extend the search
string by typing in more characters, edit it with M-e, in some fashion.
I'll admit, I haven't looked very hard for it, but it's not in Emacs
itself.

>> CC Mode is only just on the point of not supporting 19.34 any more.
>> It will carry on supporting 20.x for some years to come.  For this
>> reason, I'd prefer NEWS to carry on carrying 20.x entries.

>A split among O?NEWS(\.[1-9])? files is very arbitrary and can't
>satisfy all different needs.

>One reasonable solution would be to have only a pair of files:
>NEWS with changes only for the latest release, and ONEWS for
>all older releases.  So users have to search only two files.

Or NEWS for the current release and ANEWS for all releases (including the
current). 

>> It all boils down to the question, what is NEWS for, and whom is it
>> for?  At the top of the file it says "history of user-visible
>> changes".  To me, a "user" is somebody who's using Emacs to edit files
>> (etc.), but when she starts writing packages, becomes something more
>> than a user.

>> "history of user-visible changes" doesn't seem to be an accurate
>> discription of NEWS any more.  For the last major release, Emacs 21.1,
>> user-visible changes occupy 2170 lines, "user-invisible"
>> ("hacker-visible?") changes occupy 2196 lines.  Maybe an extract of
>> NEWS containing only user-visible changes would be a good thing.

>NEWS is only for users.  Hackers read news from ChangeLog files.

Thanks for that tip.  ;-)

>Juri Linkov

-- 
Alan Mackenzie (Munich, Germany)
address@hidden