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

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

[Kim F. Storm]

NEWS is currently +12000 lines.

Maybe we should move the +4000 lines related to 20.x to ONEWS.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> NEWS is currently +12000 lines.
>
> Maybe we should move the +4000 lines related to 20.x to ONEWS.

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!

Ideally, NEWS should have a version number in its extension:

NEWS.20.1
NEWS.20.2
NEWS.20.3
NEWS.20.4
NEWS.20.5
NEWS.20.6
NEWS.20.7
NEWS.21.1
NEWS.21.2
NEWS.21.3
NEWS.21.4

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.*

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I must say that having news for old releases in one file is very
> inconvenient.

I agree, I've often been annoyed by this.  It's a bit hard to say what's
better though -- it really depends on the version the user is upgrading
from, and we can't know that!

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

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

[David Kastrup]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Juri Linkov <juri@jurta.org> writes:
> > I must say that having news for old releases in one file is very
> > inconvenient.
> 
> I agree, I've often been annoyed by this.  It's a bit hard to say what's
> better though -- it really depends on the version the user is upgrading
> from, and we can't know that!

Well, customize-variable could also record the two last Emacs minor
and major Emacs versions valid on each change, and then the NEWS file
gets narrowed accordingly by C-h n.

Never say "we can't".  The question is rather whether it is worth the
trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> > I agree, I've often been annoyed by this.  It's a bit hard to say what's
> > better though -- it really depends on the version the user is upgrading
> > from, and we can't know that!
> 
> Well, customize-variable could also record the two last Emacs minor
> and major Emacs versions valid on each change, and then the NEWS file
> gets narrowed accordingly by C-h n.
> 
> Never say "we can't".  The question is rather whether it is worth the
> trouble.

Indeed.  :-)

That would be a cute hack, but I suspect it could cause a lot of
confusion in some circumstances!

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

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

[Stefan Monnier]

>> Well, customize-variable could also record the two last Emacs minor
>> and major Emacs versions valid on each change, and then the NEWS file
>> gets narrowed accordingly by C-h n.

Maybe something more reliable would be to record the "last and current"
version when the user hits C-h n, so you don't show "news in this new
version", but "news since you last read news".

Of course, the user might not read all the news at the same time, so
a second C-h n in the same Emacs version should show the same
news as the first one.


        Stefan

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

[Juri Linkov]

>>> Well, customize-variable could also record the two last Emacs minor
>>> and major Emacs versions valid on each change, and then the NEWS file
>>> gets narrowed accordingly by C-h n.

I really wouldn't want to make a mountain out of a molehill,
but I think an idea to automatically narrow O?NEWS.([1-9])?
to the selected release is very good for Emacs users.

I propose to replace the function `view-emacs-news' (whose
current numeric argument has no sense) by the following function.
It allows the user to select a release number, finds it among
different news files, and narrows the buffer to the selected
release.

(defun view-emacs-news (&optional release map)
  "Display info on recent changes to Emacs."
  (interactive
   (let* ((map (sort
                (delete-dups
                 (mapcan
                  (lambda (file)
                    (with-temp-buffer
                      (insert-file-contents
                       (expand-file-name file data-directory))
                      (let (res)
                        (while (re-search-forward
                                "Changes in \\(?:Emacs\\|version\\)?[ \t]*\\([0-9]+\\(?:\.[0-9]+\\)?\\)"
                                nil t)
                          (setq res (cons (list (match-string-no-properties 1) file) res)))
                        res)))
                  (append '("NEWS" "ONEWS")
                          (directory-files data-directory nil
                                           "^ONEWS\\.[0-9]+$" nil))))
                (lambda (a b)
                  (string< (car b) (car a)))))
          (release (caar map)))
     (list (completing-read
            (format "Read NEWS for the release (default %s): " release)
            (mapcar 'car map) nil nil nil nil release)
           map)))
  (let* ((file (cadr (assoc release map))))
    (if (not file)
	(error "No news is good news")
      (view-file (expand-file-name file data-directory))
      (widen)
      (goto-char (point-min))
      (when (re-search-forward
             (concat "Changes in \\(?:Emacs\\|version\\)?[ \t]*" release)
             nil t)
        (beginning-of-line)
        (narrow-to-region
         (point)
         (save-excursion
           (while (or (and (or
                            (re-search-forward
                             "Changes in \\(?:Emacs\\|version\\)?[ \t]*\\([0-9]+\\(?:\.[0-9]+\\)?\\)"
                             nil t)
                            (re-search-forward
                             "For older news, see the file ONEWS"
                             nil t))
                           (equal (match-string-no-properties 1) release))))
           (beginning-of-line)
           (point)))))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

    I propose to replace the function `view-emacs-news' (whose
    current numeric argument has no sense) by the following function.
    It allows the user to select a release number, finds it among
    different news files, and narrows the buffer to the selected
    release.

It sounds like a good feature.  However, I think it is important to
optimize it by terminating the loop that inserts files once it has
found the specified version.

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

[Richard Stallman]

    Ideally, NEWS should have a version number in its extension:

No, that means lots of small files!

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

[Alan Mackenzie]

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.

>Ideally, NEWS should have a version number in its extension:

>NEWS.20.1
>NEWS.20.2
>NEWS.20.3
>NEWS.20.4
>NEWS.20.5
>NEWS.20.6
>NEWS.20.7
>NEWS.21.1
>NEWS.21.2
>NEWS.21.3
>NEWS.21.4

>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.

If NEWS were to be split up as described, I'd have to formulate a grep
command.  [Aside:  Emacs facilities for searching through several files
seem strangely poor.]

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.

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.

>Juri Linkov

-- 
Alan Mackenzie (Munich, Germany)
acm@muc.de

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

[Juri Linkov]

Alan Mackenzie <acm@muc.de> 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.

>>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])?.

> 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.

> [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?

> 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.

> 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.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Alan Mackenzie]

On Sat, 17 Apr 2004, Juri Linkov wrote:

>Alan Mackenzie <acm@muc.de> 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)
acm@muc.de

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

[Adrian Aichner]

Alan Mackenzie <acm@muc.de> writes:

> 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.

Hi Alan, XEmacs has
 list-matches-in-buffers
in search=buffers.el, which is part of the edit-utils package.

Emacs has simpilar extentions I seem to recall reading about in the
emacswiki.

Heck, the emacswiki isn't that far away, so here is the reference:
http://www.emacswiki.org/cgi-bin/wiki.pl/SearchBuffers

In general I have to agree though, that novices should be given too
much rather than too little information to start with.

Experts can easily write something up to not see all the old NEWS.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

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

[Adrian Aichner]

Adrian Aichner <adrian@xemacs.org> writes:

Oh boy, two typos in one email:

> in search=buffers.el, which is part of the edit-utils package.

s/search=buffers/search-buffers/

> Emacs has simpilar extentions I seem to recall reading about in the

s/simpilar/similar/

> emacswiki.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

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

[Kim F. Storm]

Alan Mackenzie <acm@muc.de> writes:

> >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.  ;-(

To me it seems sensible for C-c C-u to set a mark before jumping for
the first time, while repeating C-c C-u immediately shouldn't set a
mark.

WDOT?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Kai Grossjohann]

storm@cua.dk (Kim F. Storm) writes:

> To me it seems sensible for C-c C-u to set a mark before jumping for
> the first time, while repeating C-c C-u immediately shouldn't set a
> mark.

Right.

Kai

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

[Alan Mackenzie]

On 18 Apr 2004, Kim F. Storm wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> >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.  ;-(

>To me it seems sensible for C-c C-u to set a mark before jumping for
>the first time, while repeating C-c C-u immediately shouldn't set a
>mark.

>WDOT?

C-M-u (in programming modes) doesn't set the mark, and this is (for me at
any rate) correct.  I don't want my mark stack flooded out with
uninteresting places, typically 20 or 10 or fewer lines apart. 

On the other hand, I've often wondered whether C-M-a ought to set the
mark.  I often do a C-u C-<space> first.  Maybe I should try advising
C-M-[ae] to set the mark.

I don't use Outline mode much (in fact only for reading NEWS).  Is C-c
C-u more like C-M-u or more like C-M-a?  Maybe `beginning-of-defun'
should jump to the highest level enclosing heading in outline mode, and
maybe it should set the mark, too.  It would be trivial to code, since
there's a hook already there specially for this purpose
(`beginning-of-defun-function').

>Kim F. Storm <storm@cua.dk> http://www.cua.dk

-- 
Alan Mackenzie (Munich, Germany)
acm@muc.de

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

[Juri Linkov]

Alan Mackenzie <acm@muc.de> writes:
> C-M-u (in programming modes) doesn't set the mark, and this is (for me at
> any rate) correct.  I don't want my mark stack flooded out with
> uninteresting places, typically 20 or 10 or fewer lines apart. 
>
> On the other hand, I've often wondered whether C-M-a ought to set the
> mark.  I often do a C-u C-<space> first.  Maybe I should try advising
> C-M-[ae] to set the mark.

Setting the mark by C-M-a is very useful when the user uses it to jump
to the function's beginning to see its arguments and wants to return
back to the original place.  However, the mark shouldn't be set when
the user uses C-M-a to move the point between defuns.

> I don't use Outline mode much (in fact only for reading NEWS).  Is C-c
> C-u more like C-M-u or more like C-M-a?  Maybe `beginning-of-defun'
> should jump to the highest level enclosing heading in outline mode, and
> maybe it should set the mark, too.  It would be trivial to code, since
> there's a hook already there specially for this purpose
> (`beginning-of-defun-function').

The highest level can be reached by giving a sufficiently large
argument to the `outline-up-heading' function.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
> > C-M-u (in programming modes) doesn't set the mark, and this is (for me at
> > any rate) correct.  I don't want my mark stack flooded out with
> > uninteresting places, typically 20 or 10 or fewer lines apart. 
> >
> > On the other hand, I've often wondered whether C-M-a ought to set the
> > mark.  I often do a C-u C-<space> first.  Maybe I should try advising
> > C-M-[ae] to set the mark.
> 
> Setting the mark by C-M-a is very useful when the user uses it to jump
> to the function's beginning to see its arguments and wants to return
> back to the original place.  However, the mark shouldn't be set when
> the user uses C-M-a to move the point between defuns.

So it should only set the mark if the previous command was not C-M-a.

> 
> > I don't use Outline mode much (in fact only for reading NEWS).  Is C-c
> > C-u more like C-M-u or more like C-M-a?  Maybe `beginning-of-defun'
> > should jump to the highest level enclosing heading in outline mode, and
> > maybe it should set the mark, too.  It would be trivial to code, since
> > there's a hook already there specially for this purpose
> > (`beginning-of-defun-function').
> 
> The highest level can be reached by giving a sufficiently large
> argument to the `outline-up-heading' function.


C-u C-c C-u ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> Juri Linkov <juri@jurta.org> writes:
>> Alan Mackenzie <acm@muc.de> writes:
>> > On the other hand, I've often wondered whether C-M-a ought to set the
>> > mark.  I often do a C-u C-<space> first.  Maybe I should try advising
>> > C-M-[ae] to set the mark.
>> 
>> Setting the mark by C-M-a is very useful when the user uses it to jump
>> to the function's beginning to see its arguments and wants to return
>> back to the original place.  However, the mark shouldn't be set when
>> the user uses C-M-a to move the point between defuns.
>
> So it should only set the mark if the previous command was not C-M-a.

Yes, it looks right.

>> The highest level can be reached by giving a sufficiently large
>> argument to the `outline-up-heading' function.
>
> C-u C-c C-u ?

Usually, this is enough to reach the top level, but for reliability
the numeric argument should be 1000 (the magic constant used in many
places related to outline-mode).

Anyhow, the following patches set the mark for C-M-a and C-M-e
in programming modes, and for C-c C-u in outline mode.

BTW, I think isearch should not set the mark at the beginning of the
buffer.  Often users move the point to the beginning to start the
search from the top.  It's too inconvenient to have this position in
the mark ring to go back to the original position.  And moreover,
the beginning of the buffer can be reached very easily when needed
without going through the mark ring.

Index: lisp/emacs-lisp/lisp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.52
diff -u -r1.52 lisp.el
--- lisp/emacs-lisp/lisp.el	14 Apr 2004 18:20:23 -0000	1.52
+++ lisp/emacs-lisp/lisp.el	25 Apr 2004 04:58:59 -0000
@@ -175,6 +175,8 @@
 If variable `beginning-of-defun-function' is non-nil, its value
 is called as a function to find the defun's beginning."
   (interactive "p")
+  (and (eq this-command 'beginning-of-defun)
+       (or (eq last-command 'beginning-of-defun) (push-mark)))
   (and (beginning-of-defun-raw arg)
        (progn (beginning-of-line) t)))
 
@@ -223,6 +225,8 @@
 If variable `end-of-defun-function' is non-nil, its value
 is called as a function to find the defun's end."
   (interactive "p")
+  (and (eq this-command 'end-of-defun)
+       (or (eq last-command 'end-of-defun) (push-mark)))
   (if (or (null arg) (= arg 0)) (setq arg 1))
   (if end-of-defun-function
       (if (> arg 0)

Index: lisp/outline.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/outline.el,v
retrieving revision 1.5
diff -u -r1.5 outline.el
--- lisp/outline.el	21 Jan 2004 03:25:37 -0000	1.5
+++ lisp/outline.el	25 Apr 2004 05:03:02 -0000
@@ -884,6 +879,8 @@
 With argument, move up ARG levels.
 If INVISIBLE-OK is non-nil, also consider invisible lines."
   (interactive "p")
+  (and (eq this-command 'outline-up-heading)
+       (or (eq last-command 'outline-up-heading) (push-mark)))
   (outline-back-to-heading invisible-ok)
   (let ((start-level (funcall outline-level)))
     (if (eq start-level 1)

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.226
diff -u -r1.226 isearch.el
--- lisp/isearch.el	4 Mar 2004 16:54:08 -0000	1.226
+++ lisp/isearch.el	25 Apr 2004 04:39:34 -0000
@@ -699,9 +700,9 @@
       ;; Exiting the save-window-excursion clobbers window-start; restore it.
       (set-window-start (selected-window) found-start t))
 
-    ;; If there was movement, mark the starting position.
+    ;; If there was movement, mark the starting position (except at bob).
     ;; Maybe should test difference between and set mark iff > threshold.
-    (if (/= (point) isearch-opoint)
+    (if (and (/= (point) isearch-opoint) (/= isearch-opoint (point-min)))
 	(or (and transient-mark-mode mark-active)
 	    (progn
 	      (push-mark isearch-opoint t)

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

I think we should poll the users about the proposed change to C-M-a
etc.

    BTW, I think isearch should not set the mark at the beginning of the
    buffer.  Often users move the point to the beginning to start the
    search from the top.

I think the inconsistency of this change would be bigger than the
benefit.

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

[Juri Linkov]

>     BTW, I think isearch should not set the mark at the beginning of the
>     buffer.  Often users move the point to the beginning to start the
>     search from the top.
>
> I think the inconsistency of this change would be bigger than the
> benefit.

I doubt users will even notice it.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> > I think the inconsistency of this change would be bigger than the
> > benefit.
> 
> I doubt users will even notice it.

I feel pretty sure that when it _does_ noticed (and it will), it will be
_extremely_ confusing.  Invisible side-effects like isearch setting the
mark are already hard enough to grok without adding special cases like
that (unless there's a very strong advantage to having the incosistency,
and I don't think that's true here).

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

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

[Richard Stallman]

    > I think the inconsistency of this change would be bigger than the
    > benefit.

    I doubt users will even notice it.

People who assume that C-s sets the mark, and have habits taking
advantage of that, will notice that sometimes these habits sometimes
don't work any more.

isearch (was: Re: Should we move 20.x related stuff out of NEWS ?)

[Juri Linkov]

Alan Mackenzie <acm@muc.de> writes:
> 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.

I sometimes wished this feature too.  For example, isearch implemented
in the standalone Info reader can jump to the next Info node, but
Emacs can't.  Something similar could be implemented in Emacs as well:
for Emacs Info reader to jump between Info nodes, and for non-Info
buffers to jump between buffers.  However, there is one question:
how to define the order in which isearch will visit buffers.
Perhaps, most useful is by recency, but the user should be able
to define the desired order somehow.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch (was: Re: Should we move 20.x related stuff out of NEWS ?)

[Richard Stallman]

    I sometimes wished this feature too.  For example, isearch implemented
    in the standalone Info reader can jump to the next Info node, but
    Emacs can't.  Something similar could be implemented in Emacs as well:
    for Emacs Info reader to jump between Info nodes, and for non-Info
    buffers to jump between buffers.

I don't like the idea of complicating isearch this way.
It is better to keep isearch with its natural meaning, which is to
search the current visible buffer contents, and have the separate
info search that knows how to move beteeen nodes.

Re: isearch (was: Re: Should we move 20.x related stuff out of NEWS ?)

[Stefan Monnier]

>     I sometimes wished this feature too.  For example, isearch implemented
>     in the standalone Info reader can jump to the next Info node, but
>     Emacs can't.  Something similar could be implemented in Emacs as well:
>     for Emacs Info reader to jump between Info nodes, and for non-Info
>     buffers to jump between buffers.
> I don't like the idea of complicating isearch this way.

Hmmm.... odd.
I've always had the desire to extend isearch with a key binding
that allows me to switch to "the next buffer" and even to automatically
"switch to the next buffer upon reaching EOB".  Same thing for
query-replace.


        Stefan

RE: isearch (was: Re: Should we move 20.x related stuff out of NEWS ?)

[Drew Adams]

I agree with Richard on this. I often want to limit a search to the current
info node.

But I also see that someone might want to isearch beyond the current node -
especially because of isearch's behavior on failure to find, reverse search
etc.

Anyone have a *good* idea on how to get both behaviors, au choix, on the
fly?

Here's a rudimentary solution: If reach info node end, display "Failing
I-search in node foobar". Then, another C-s continues searching in the
following node. That is, replace isearch wrapping in the same node by
continuing to another node. This could be an option -
isearch-wrap-at-info-node-end or some such.

Whatever mechanism were adopted, a similar mechanism might be used for
isearching multiple buffers. I know that there are packages out there to do
that, but I haven't tried them.

  - Drew

-----Original Message-----
From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
[mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org]On Behalf Of
Stefan Monnier
Sent: Friday, April 23, 2004 10:44 AM
To: rms@gnu.org
Cc: Juri Linkov; acm@muc.de; emacs-devel@gnu.org
Subject: Re: isearch (was: Re: Should we move 20.x related stuff out of
NEWS ?)


>     I sometimes wished this feature too.  For example, isearch implemented
>     in the standalone Info reader can jump to the next Info node, but
>     Emacs can't.  Something similar could be implemented in Emacs as well:
>     for Emacs Info reader to jump between Info nodes, and for non-Info
>     buffers to jump between buffers.
> I don't like the idea of complicating isearch this way.

Hmmm.... odd.
I've always had the desire to extend isearch with a key binding
that allows me to switch to "the next buffer" and even to automatically
"switch to the next buffer upon reaching EOB".  Same thing for
query-replace.

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

[Richard Stallman]

    NEWS is currently +12000 lines.

    Maybe we should move the +4000 lines related to 20.x to ONEWS.

Yes, I think so.