next-error-last-buffer

next-error-last-buffer

[Juri Linkov]

The current treatment of the `next-error-last-buffer' variable
is very inconvenient, because it is not possible to continue
visiting source files from a compilation other than the latest
compilation.

I think that `next-error-last-buffer' should be set buffer-locally
in the compilation buffer as well as in every source file visited
from that compilation buffer.  Thus calling `next-error' on a
visited buffer or a compilation buffer will continue visiting
locations for the same compilation from which a visited buffer
was found or a compilation buffer was created.

Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.642
diff -u -r1.642 simple.el
--- lisp/simple.el	7 May 2004 22:31:54 -0000	1.642
+++ lisp/simple.el	9 May 2004 00:38:21 -0000
@@ -152,10 +152,12 @@
 \`compilation-error-regexp-alist' for customization ideas."
   (interactive "P")
   (if (consp arg) (setq reset t arg nil))
-  (when (setq next-error-last-buffer (next-error-find-buffer))
+  (when (setq-default next-error-last-buffer (next-error-find-buffer))
     ;; we know here that next-error-function is a valid symbol we can funcall
     (with-current-buffer next-error-last-buffer
-      (funcall next-error-function (prefix-numeric-value arg) reset))))
+      (set (make-local-variable 'next-error-last-buffer) next-error-last-buffer)
+      (funcall next-error-function (prefix-numeric-value arg) reset)
+      (set (make-local-variable 'next-error-last-buffer) next-error-last-buffer))))
 
 (defalias 'goto-next-locus 'next-error)
 (defalias 'next-match 'next-error)

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

Re: next-error-last-buffer

[Richard Stallman]

    I think that `next-error-last-buffer' should be set buffer-locally
    in the compilation buffer

Isn't next-error in a compilation buffer already supposed to operate
on the current buffer?  If so, this change would be a no-op.
It might be that this is a cleaner way to implement that feature
than the code that currently implements it.

			      as well as in every source file visited
    from that compilation buffer.

That is an interesting idea, but I think it will screw up the
interaction between compilation and occur, which was the whole point
of the recent changes.

Re: next-error-last-buffer

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     I think that `next-error-last-buffer' should be set buffer-locally
>     in the compilation buffer
>
> Isn't next-error in a compilation buffer already supposed to operate
> on the current buffer?  If so, this change would be a no-op.
> It might be that this is a cleaner way to implement that feature
> than the code that currently implements it.

Yes, setting `next-error-last-buffer' locally in the compilation
buffer is not necessary with the current logic in `next-error-find-buffer',
but it could be set only for consistency.

> 			      as well as in every source file visited
>     from that compilation buffer.
>
> That is an interesting idea, but I think it will screw up the
> interaction between compilation and occur, which was the whole point
> of the recent changes.

I tested this change, and it seems to work correctly with occur,
i.e. it allows to continue visiting next occurrences from the same
occur buffer where the current source buffer was visited from,
even if it is not from the last occur/compile/grep.

However, `occur-next-error' has its own problems that should be fixed
(it can't jump to multiple occurrences on the same line, it don't move
the point in the occur buffer like `compilation-goto-locus' does).

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

Re: next-error-last-buffer

[Richard Stallman]

    I tested this change, and it seems to work correctly with occur,
    i.e. it allows to continue visiting next occurrences from the same
    occur buffer where the current source buffer was visited from,
    even if it is not from the last occur/compile/grep.

If you switch to another source buffer that was last reached
through C-x ` from a compilation error, then C-x ` will get the
next compilation error, rather than the next occurrence.
At least, it sounds like your change would have that result.

I don't think that is the right behavior.

Re: next-error-last-buffer

[Stefan Monnier]

> If you switch to another source buffer that was last reached
> through C-x ` from a compilation error, then C-x ` will get the
> next compilation error, rather than the next occurrence.
> At least, it sounds like your change would have that result.

Indeed.  In order to get the right behavior in all cases, we'd need
to read the user's mind.  So the current approach at least has the
advantage of being simple for the user to understand (and thus predict),
while working correctly for the most common cases.

We might want to make the interface more complex/powerful so the user can
explain more of what he wants, but I think the default
(i.e. which compilation buffer to choose, in the absence of any hint from
the user) should basically stay as it is.


        Stefan

Re: next-error-last-buffer

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     I tested this change, and it seems to work correctly with occur,
>     i.e. it allows to continue visiting next occurrences from the same
>     occur buffer where the current source buffer was visited from,
>     even if it is not from the last occur/compile/grep.
>
> If you switch to another source buffer that was last reached
> through C-x ` from a compilation error, then C-x ` will get the
> next compilation error, rather than the next occurrence.
> At least, it sounds like your change would have that result.

Exactly.  This is the most expected behavior, because the user
associates the buffer visited through C-x ` with the compilation
buffer from which it was visited, and will expect that next-error
will show next compilation errors in the same source buffer.

It seems nobody really tried yet to use two or more different
compile/grep/occur processes at the same time.  Otherwise,
it would be apparent that this behavior is the most useful.

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

Re: next-error-last-buffer

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> If you switch to another source buffer that was last reached
>> through C-x ` from a compilation error, then C-x ` will get the
>> next compilation error, rather than the next occurrence.
>> At least, it sounds like your change would have that result.
>
> Indeed.  In order to get the right behavior in all cases, we'd need
> to read the user's mind.  So the current approach at least has the
> advantage of being simple for the user to understand (and thus predict),
> while working correctly for the most common cases.

The current approach is simple, but unusable in real situations.

Imagine for example such a typical scenario:

1. Start compilation.  The compilation buffer is displayed in
another window.

2. Type C-x `.  A source file is visited in the same window.

3. Make a new frame.

4. Run grep or occur.  A grep or occur buffer is displayed in
another window.

5. Type C-x `.  A file found by grep or occur is visited in the same window.

6. Switch back to the initial frame.  Buffers are displayed in the same
state as they were left - with two windows: one with the source buffer
and another with the compilation buffer, and the point in the source
buffer on the line with previous error.

7. Now type C-x `.  What is the most expected behavior when the point
is located in the file visited by C-x ` is that next C-x ` will
find next errors in the same file.

But alas, the buffer is unexpectedly switched to some file which happens
to be the next found by last grep/occur.  This is very confusing.
And even if the user can remember always to switch to the compilation
buffer before typing C-x ` to make it last, it is still too inconvenient.

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

Re: next-error-last-buffer

[Stefan Monnier]

>> If you switch to another source buffer that was last reached
>> through C-x ` from a compilation error, then C-x ` will get the
>> next compilation error, rather than the next occurrence.
>> At least, it sounds like your change would have that result.

> Exactly.  This is the most expected behavior, because the user
> associates the buffer visited through C-x ` with the compilation
> buffer from which it was visited, and will expect that next-error
> will show next compilation errors in the same source buffer.

No: I do M-x compile, visit a few error in xdisp.c.
Then an hour later, I do M-x grep, follow a hit, do a M-. which brings me
to xdisp.c, then try C-x ` to get to the next hit and !bang! I'm brought
to the next error in the compilation I completely forgot about.
The main problem with your approach is that its memory lasts too long.


        Stefan

Re: next-error-last-buffer

[Richard Stallman]

    > Indeed.  In order to get the right behavior in all cases, we'd need
    > to read the user's mind.  So the current approach at least has the
    > advantage of being simple for the user to understand (and thus predict),
    > while working correctly for the most common cases.

    The current approach is simple, but unusable in real situations.

I expect the same would be true if we make the change that you
propose.

I pointed out, when we first started to unify Occur with next-error,
that finding the right way to treat these issues would be the hardest
part of the job.  On such issues it is quite common to find that
all the straightforward options are clearly wrong in some cases.

    > If you switch to another source buffer that was last reached
    > through C-x ` from a compilation error, then C-x ` will get the
    > next compilation error, rather than the next occurrence.
    > At least, it sounds like your change would have that result.

    Exactly.  This is the most expected behavior, because the user
    associates the buffer visited through C-x ` with the compilation
    buffer from which it was visited

You're assuming one scenario, but there are others just as plausible.
For instance, the user still working on looking through all the
occurrences in the Occur buffer, and looks at this other buffer
because one of its functions was called from the code at one of those
occurrences.

    It seems nobody really tried yet to use two or more different
    compile/grep/occur processes at the same time.  Otherwise,
    it would be apparent that this behavior is the most useful.

It could not hurt for more people to try these cases,
and try playing with different behaviors, so that we can
find out what is really best.

Re: next-error-last-buffer

[Ted Zlatanov]

On Tue, 11 May 2004, juri@jurta.org wrote:

> It seems nobody really tried yet to use two or more different
> compile/grep/occur processes at the same time.  Otherwise,
> it would be apparent that this behavior is the most useful.

Juri,

while I have no particular attachment to the current next-error logic
or to your replacement suggestions, I'd like to mention that my goal
when I wrote the next-error patch was NOT to facilitate multiple
grep/compile/occur processes simultaneously, but to provide a SINGLE
interface to all of them through next-error.  In other words, I wanted
C-x ` to work no matter what single task I was doing.  It's very
possible that different approaches to multiple next-error client
buffers will emerge from this discussion; my only suggestion is that
the eventual API should have a few presets, but otherwise be
function-based so users can install any logic they like.  The basic
question we want to ask the user is, "what next?" and DWIM can be
very hard with such intuitive tasks.

I'll be glad to help with suggestions and code to implement the
changes you want in the next-error API.

Thanks
Ted

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> I'll be glad to help with suggestions and code to implement the
> changes you want in the next-error API.

The current implementation of next-error framework is general enough
to allow implementing different approaches easily (for example, I was
able to implement the desired behavior with only one small change in
the `next-error' function), but it is still not extensible enough.

Based on my recent experience, I want to make some suggestions
how to make it more extensible:

1. Add an option to allow the user to select among predefined
behaviors.  Though, this will not help the user if he will not
find a desired option in the predefined set.

2. Add a new user variable `next-error-find-buffer-function' and try
to call it (i.e. to call it if it's fbound and return its value,
but if it returns `nil', try other rules) in `next-error-find-buffer'
at the top precedence level before all other rules.  This will allow
the user to override the standard rules for finding the next-error
capable buffer with his own rule.

3. Add a hook to `next-error' after the `funcall next-error-function'
to allow the user to perform actions (such as setting buffer-local
variables) in the buffer found by `next-error-function'.

Making the next-error framework more extensible is only half the job.
Finding a good default behavior is no less important.

I thought again about why the current behavior is too confusing
and I think I found the reason: the most confusing is the fact that
the compilation buffer is visible in the window adjacent to the
source file window where the point is located, but typing C-x `
uses the last but not visible compilation buffer.

So w.r.t. `next-error-find-buffer' I propose to modify it to use the
following priority order:

1(new). Try to call a user-defined `next-error-find-buffer-function'.
2. If the current buffer is a next-error capable buffer, return it.
3(new). If a next-error capable buffer is in one of the windows
        of the current frame, return it.
4. If next-error-last-buffer is set to a live buffer, use that.
5. Otherwise, look for a next-error capable buffer
6. Signal an error if there are none.

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

Re: next-error-last-buffer

[Ted Zlatanov]

On Wed, 12 May 2004, juri@jurta.org wrote:

> The current implementation of next-error framework is general enough
> to allow implementing different approaches easily (for example, I
> was able to implement the desired behavior with only one small
> change in the `next-error' function), but it is still not extensible
> enough.
> 
> Based on my recent experience, I want to make some suggestions
> how to make it more extensible:
> 
> 1. Add an option to allow the user to select among predefined
> behaviors.  Though, this will not help the user if he will not
> find a desired option in the predefined set.

What predefined behaviors should we allow?

- use the last visited buffer
- prefer {compile,grep,occur} buffers
- use the visible buffers
- user-defined function

The behavior preferences should be in a list, so the user can say "use
my function, then use the visible buffers first, then try a compile
buffer, then use the last visited buffer" for instance.  I really
think most users will be happy with a default of "last visited buffer"
but we should let the users decide by making it easy to configure.

> 2. Add a new user variable `next-error-find-buffer-function' and try
> to call it (i.e. to call it if it's fbound and return its value, but
> if it returns `nil', try other rules) in `next-error-find-buffer' at
> the top precedence level before all other rules.  This will allow
> the user to override the standard rules for finding the next-error
> capable buffer with his own rule.

I think this should be just another behavior, not an overriding
preference.  It could go in the middle of the search rules, for
instance.

> 3. Add a hook to `next-error' after the `funcall
> next-error-function' to allow the user to perform actions (such as
> setting buffer-local variables) in the buffer found by
> `next-error-function'.

I'm OK with that.

> I thought again about why the current behavior is too confusing
> and I think I found the reason: the most confusing is the fact that
> the compilation buffer is visible in the window adjacent to the
> source file window where the point is located, but typing C-x `
> uses the last but not visible compilation buffer.

You are not a typical user.  I, for instance, have NEVER run more than
one compilation at a time.  I may have to in the future, sure, but I
doubt it's typical user behavior.

> So w.r.t. `next-error-find-buffer' I propose to modify it to use the
> following priority order:
> 
> 1(new). Try to call a user-defined
> `next-error-find-buffer-function'.  2. If the current buffer is a
> next-error capable buffer, return it.  3(new). If a next-error
> capable buffer is in one of the windows of the current frame, return
> it.  4. If next-error-last-buffer is set to a live buffer, use that.
> 5. Otherwise, look for a next-error capable buffer 6. Signal an
> error if there are none.

I think the current buffer should override any other rules.  The
other rules' order should be user-configurable.

Ted

Re: next-error-last-buffer

[Richard Stallman]

    1. Add an option to allow the user to select among predefined
    behaviors.  Though, this will not help the user if he will not
    find a desired option in the predefined set.

I don't want to offer the user a choice of several behaviors
that are all unsatisfactory in various ways.  This way lies
lots of complexity without really satisfying anyone.

What we should do, when we see how, is make the default behavior
better.

    2. Add a new user variable `next-error-find-buffer-function' and try
    to call it (i.e. to call it if it's fbound and return its value,
    but if it returns `nil', try other rules) in `next-error-find-buffer'
    at the top precedence level before all other rules.

Is this really an improvement?  It is not that hard for users
who want different behavior to edit the code.

    I thought again about why the current behavior is too confusing
    and I think I found the reason: the most confusing is the fact that
    the compilation buffer is visible in the window adjacent to the
    source file window where the point is located, but typing C-x `
    uses the last but not visible compilation buffer.

Perhaps next-error should always choose a compilation or occur buffer
that is visible in a window, rather than one that isn't.  And it
should prefer one that is visible in the current frame to one that is
visible in another frame.  This might help us get a better default
behavior.

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> What predefined behaviors should we allow?
>
> - use the last visited buffer
> - prefer {compile,grep,occur} buffers
> - use the visible buffers
> - user-defined function
>
> The behavior preferences should be in a list, so the user can say "use
> my function, then use the visible buffers first, then try a compile
> buffer, then use the last visited buffer" for instance.  I really
> think most users will be happy with a default of "last visited buffer"
> but we should let the users decide by making it easy to configure.

Defining rules by a list would be good.  For example:

(defcustom next-error-find-buffer-functions
  '(next-error-visible-buffer         ; predefined function
    next-error-find-buffer-function   ; user-defined
    next-error-last-buffer            ; predefined function
    ...)
  :type '(repeat symbol))

But isn't this unnecessarily complicated?

>> I thought again about why the current behavior is too confusing
>> and I think I found the reason: the most confusing is the fact that
>> the compilation buffer is visible in the window adjacent to the
>> source file window where the point is located, but typing C-x `
>> uses the last but not visible compilation buffer.
>
> You are not a typical user.  I, for instance, have NEVER run more than
> one compilation at a time.  I may have to in the future, sure, but I
> doubt it's typical user behavior.

So we are free to define any default behavior of selecting the compilation
buffer because any our decision will not affect typical users ;-)

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

Re: next-error-last-buffer

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     2. Add a new user variable `next-error-find-buffer-function' and try
>     to call it (i.e. to call it if it's fbound and return its value,
>     but if it returns `nil', try other rules) in `next-error-find-buffer'
>     at the top precedence level before all other rules.
>
> Is this really an improvement?  It is not that hard for users
> who want different behavior to edit the code.

With the goal to improve configurability of the rules for finding
an appropriate compilation buffer this is really an improvement.
But with a list of rules suggested by Ted, there will be no need
in a special variable for user-defined function.

>     I thought again about why the current behavior is too confusing
>     and I think I found the reason: the most confusing is the fact that
>     the compilation buffer is visible in the window adjacent to the
>     source file window where the point is located, but typing C-x `
>     uses the last but not visible compilation buffer.
>
> Perhaps next-error should always choose a compilation or occur buffer
> that is visible in a window, rather than one that isn't.  And it
> should prefer one that is visible in the current frame to one that is
> visible in another frame.  This might help us get a better default
> behavior.

It seems this behavior will satisfy most users.

BTW, there is one related inconvenience in the compilation functionality:
when there is the compilation window on another frame, starting compilation
places another frame over the current frame, but doesn't make it active.
This is because in the function `compilation-start' the `frame' argument
of `display-buffer' is `t':

   (display-buffer outbuf nil t)
                              ^--- consider windows on all frames

Why should compilation insist on switching frames?  Shouldn't
`display-buffer-reuse-frames' define the user preference instead?

So I think `display-buffer' should use the default values:

diff -u emacs/lisp/progmodes/compile.el~ emacs/lisp/progmodes/compile.el
@@ -898,7 +905,7 @@
     (if (eq outbuf (current-buffer))
 	(goto-char (point-max)))
     ;; Pop up the compilation buffer.
-    (setq outwin (display-buffer outbuf nil t))
+    (setq outwin (display-buffer outbuf))
     (with-current-buffer outbuf
       (if (not (eq mode t))
 	  (funcall mode)

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

Re: next-error-last-buffer

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>    (display-buffer outbuf nil t)
>                               ^--- consider windows on all frames
> 
> Why should compilation insist on switching frames?  Shouldn't
> `display-buffer-reuse-frames' define the user preference instead?

It's not `switching frames', it's _using_ an existing compilation buffer
in a different frame.

This is good -- the previous behavior (which didn't do that) was very
annoying: if you happened to have a *compilation* buffer displayed in
another frame, starting a compilation would none-the-less insist on
popping up another window in _this_ frame, resulting in two redundant
windows showing the *compilation* buffer.

> So I think `display-buffer' should use the default values:

No.

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: next-error-last-buffer

[Stefan Monnier]

>> (display-buffer outbuf nil t)
[...]
> This is good -- the previous behavior (which didn't do that) was very
> annoying: if you happened to have a *compilation* buffer displayed in
> another frame, starting a compilation would none-the-less insist on
> popping up another window in _this_ frame, resulting in two redundant
> windows showing the *compilation* buffer.

I should actually use 0 rather than t.


        Stfean

Re: next-error-last-buffer

[Juri Linkov]

Miles Bader <miles@lsi.nec.co.jp> writes:
> Juri Linkov <juri@jurta.org> writes:
>>    (display-buffer outbuf nil t)
>>                               ^--- consider windows on all frames
>> 
>> Why should compilation insist on switching frames?  Shouldn't
>> `display-buffer-reuse-frames' define the user preference instead?
>
> It's not `switching frames', it's _using_ an existing compilation buffer
> in a different frame.
>
> This is good -- the previous behavior (which didn't do that) was very
> annoying: if you happened to have a *compilation* buffer displayed in
> another frame, starting a compilation would none-the-less insist on
> popping up another window in _this_ frame, resulting in two redundant
> windows showing the *compilation* buffer.

So what?  I have no objection to having two compilation buffers
on different frames.

But the current behavior is more annoying: another frame is raised over
the current frame, but is not activated.  So you see the inactive
frame with the point in the other frame.

>> So I think `display-buffer' should use the default values:
>
> No.

But there is the variable `display-buffer-reuse-frames' for users who
like to reuse windows on another frames.  I even have no objections
to changing its default value to t, since I can change it to nil in .emacs.
But there is no way to ignore the frame argument of `display-buffer'
if it's specified explicitly.

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

Re: next-error-last-buffer

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> But there is the variable `display-buffer-reuse-frames' for users who
> like to reuse windows on another frames.

That is too general: it affects _all_ use of display-buffer, including,
crucially, `pop-to-buffer'.  In that context, the effect is not just
annoying, it's downright dangerous (as the user expects the keyboard
focus to be the new popped-to buffer -- and it _looks_ like it is
because the window is raised -- but in fact, the frame focus doesn't
change).

So setting `display-buffer-reuse-frames' to t is not reasonable.

> I even have no objections to changing its default value to t, since I
> can change it to nil in .emacs.  But there is no way to ignore the
> frame argument of `display-buffer' if it's specified explicitly.

If it really drives you nuts, make a special variable for this case or
something.  But please don't change the existing behavior.

-Miles
-- 
I'd rather be consing.

Re: next-error-last-buffer

[Ted Zlatanov]

On Wed, 12 May 2004, rms@gnu.org wrote:

> I don't want to offer the user a choice of several behaviors
> that are all unsatisfactory in various ways.  This way lies
> lots of complexity without really satisfying anyone.
> 
> What we should do, when we see how, is make the default behavior
> better.

Considering all the possible modes that can use next-error, I feel
that users would appreciate some control over the process of choosing
the next-error buffer.

With that in mind, why not make the default behavior a list of symbols
as Juri and I suggested, with a sensible default as you suggest?  Here
are the advantages:

1) the user does not have to know how the default behavior works,
   they just use it

2) we can change the default behavior with a change of customize
   defaults, not a change of logic

3) the user can, if he chooses, override the defaults easily through
   the customization facilities

Ted

Re: next-error-last-buffer

[Ted Zlatanov]

On Thu, 13 May 2004, juri@jurta.org wrote:

> Defining rules by a list would be good.  For example:
> 
> (defcustom next-error-find-buffer-functions
>   '(next-error-visible-buffer         ; predefined function
>     next-error-find-buffer-function   ; user-defined
>     next-error-last-buffer            ; predefined function
>     ...)
>   :type '(repeat symbol))
> 
> But isn't this unnecessarily complicated?

I think it's necessary in order to accomodate both you and RMS.

Ted

Re: next-error-last-buffer

[Richard Stallman]

    With that in mind, why not make the default behavior a list of symbols
    as Juri and I suggested, with a sensible default as you suggest?

Let's change the default behavior and see if anyone is really unhappy
afterwards.

Re: next-error-last-buffer

[Ted Zlatanov]

On Fri, 14 May 2004, rms@gnu.org wrote:

    > With that in mind, why not make the default behavior a list of
    > symbols
>     as Juri and I suggested, with a sensible default as you suggest?
> 
> Let's change the default behavior and see if anyone is really
> unhappy afterwards.

Is this the change you want?

"Perhaps next-error should always choose a compilation or occur buffer
that is visible in a window, rather than one that isn't.  And it
should prefer one that is visible in the current frame to one that is
visible in another frame.  This might help us get a better default
behavior."

Thanks
Ted

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 14 May 2004, rms@gnu.org wrote:
>> Let's change the default behavior and see if anyone is really
>> unhappy afterwards.
>
> Is this the change you want?
>
> "Perhaps next-error should always choose a compilation or occur buffer
> that is visible in a window, rather than one that isn't.  And it
> should prefer one that is visible in the current frame to one that is
> visible in another frame.  This might help us get a better default
> behavior."

I think the following default behavior is good enough:

1. If the current buffer is a next-error capable buffer, return it.
2(new). If one and only one window on the current frame displays
        a next-error capable buffer, return this buffer.
3. If next-error-last-buffer is set to a live buffer, use that.
4. Otherwise, look for a next-error capable buffer in the buffer list.
5. Signal an error if there are none.

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

Re: next-error-last-buffer

[Richard Stallman]

    Is this the change you want?

    "Perhaps next-error should always choose a compilation or occur buffer
    that is visible in a window, rather than one that isn't.  And it
    should prefer one that is visible in the current frame to one that is
    visible in another frame.  This might help us get a better default
    behavior."

Yes, that's what I think we should try first.  This will make the more
natural choice in many cases, and will give people a natural way to
choose which compilation or occur buffer to use.  Perhaps when people
get used to this there will not be a need for further changes.

Re: next-error-last-buffer

[Richard Stallman]

    I think the following default behavior is good enough:

    1. If the current buffer is a next-error capable buffer, return it.
    2(new). If one and only one window on the current frame displays
	    a next-error capable buffer, return this buffer.
    3. If next-error-last-buffer is set to a live buffer, use that.
    4. Otherwise, look for a next-error capable buffer in the buffer list.
    5. Signal an error if there are none.

Ok, let's do that.

Re: next-error-last-buffer

[Juri Linkov]

There is another problem related to `next-error-last-buffer'.

When `next-error' visits a next-error capable buffer, it continues
to visit places from that buffer instead of the original buffer
from which it was found.

This problem occurs when going through results in a grep buffer
visits a patch file in diff mode.  The next call of `next-error'
continues to visit places from a patch file, not from a grep buffer.

To avoid this problem, the variable `next-error-function' could be set
to nil in a buffer visited by the latest call of `next-error-function'.

Index: lisp/simple.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/simple.el,v
retrieving revision 1.644
diff -u -r1.644 simple.el
--- lisp/simple.el	23 May 2004 21:01:15 -0000	1.644
+++ lisp/simple.el	24 May 2004 07:32:57 -0000
@@ -168,7 +168,9 @@
   (when (setq next-error-last-buffer (next-error-find-buffer))
     ;; we know here that next-error-function is a valid symbol we can funcall
     (with-current-buffer next-error-last-buffer
-      (funcall next-error-function (prefix-numeric-value arg) reset))))
+      (funcall next-error-function (prefix-numeric-value arg) reset)
+      ;; make buffers visited by next-error-function not a next-error capable
+      (if (and next-error-function (not (eq (current-buffer) next-error-last-buffer)))
+          (setq next-error-function nil)))))
 
 (defalias 'goto-next-locus 'next-error)
 (defalias 'next-match 'next-error)

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

Re: next-error-last-buffer

[Ted Zlatanov]

On Mon, 24 May 2004, juri@jurta.org wrote:

> There is another problem related to `next-error-last-buffer'.
> 
> When `next-error' visits a next-error capable buffer, it continues
> to visit places from that buffer instead of the original buffer
> from which it was found.
> 
> This problem occurs when going through results in a grep buffer
> visits a patch file in diff mode.  The next call of `next-error'
> continues to visit places from a patch file, not from a grep buffer.

Excellent catch, I had not seen that problem.  I don't know if it's a
bug, though!

> To avoid this problem, the variable `next-error-function' could be set
> to nil in a buffer visited by the latest call of
> `next-error-function'.

But what if the user wants the next place in the patch file?  It
would be very useful to have next-error support that as well.

Maybe next-error should know when a user visits a buffer
interactively (with a keyboard command or a mouse click) versus
through a next-error invocation.  That way, the user can select the
diff buffer manually when they want the next diff hunk, but otherwise
next-error will keep using the original invocant buffer.

Ted

Re: next-error-last-buffer

[Richard Stallman]

    This problem occurs when going through results in a grep buffer
    visits a patch file in diff mode.  The next call of `next-error'
    continues to visit places from a patch file, not from a grep buffer.

    To avoid this problem, the variable `next-error-function' could be set
    to nil in a buffer visited by the latest call of `next-error-function'.

This fix has a drawback; it will make that buffer permanently
incapable of being used as a series of references to places.

I think we should look for a way to disable this temporarily instead.
However, I am not sure how that would work--what would be the
condition on which to reenable this buffer's value of
next-error-function?

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> But what if the user wants the next place in the patch file?  It
> would be very useful to have next-error support that as well.
>
> Maybe next-error should know when a user visits a buffer
> interactively (with a keyboard command or a mouse click) versus
> through a next-error invocation.  That way, the user can select the
> diff buffer manually when they want the next diff hunk, but otherwise
> next-error will keep using the original invocant buffer.

When users want to go to the next place in the patch file they can
revisit it by killing a buffer and visiting it again (e.g. by C-x C-f).
This way the variable `next-error-function' will be set again
in that buffer.

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

Re: next-error-last-buffer

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> This fix has a drawback; it will make that buffer permanently
> incapable of being used as a series of references to places.
>
> I think we should look for a way to disable this temporarily instead.
> However, I am not sure how that would work--what would be the
> condition on which to reenable this buffer's value of
> next-error-function?

If there is a real need to enable next-error-function in the existing
buffer visited by next-error (i.e. if it's not too rare case when the
user needs to kill a buffer and create a new, that may be inconvenient
if performed too often), then next-error-function could be enabled again
by setting it to the initial value by typing C-m or one of other error
visiting keys available in the next-error capable buffer.  When these
keys are bound to one of the following functions, each function could
set the initial value of next-error-function every time it called
in the next-error capable buffer:

compile-goto-error
diff-goto-source
occur-mode-goto-occurrence

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

Re: next-error-last-buffer

[Juri Linkov]

It seems more work is needed to generalize the next-error framework
for different modes.  The functions next-error-*, previous-error-*
is a good start, but there are still similar functions with different
names in compile/grep/occur/diff.  And what is worse is that all these
modes have different keybindings for similar functions.

Below is a proposal for unification of command names and keybindings.
On the first indentation level there is a new command name with
unified keybindings.  On the second level - mode map name.  On the
third level - the current keybinding and command name.

goto-error: C-m, C-c C-c, M-o
  compilation-mode-map
    C-c C-c  compile-goto-error
    C-m      compile-goto-error
  grep-mode-map
    \r       compile-goto-error
  diff-mode-shared-map
    C-M-m    diff-goto-source
    M-o      diff-goto-source
    C-c C-c  diff-goto-source
  occur-mode-map
    C-c C-c  occur-mode-goto-occurrence
    C-m      occur-mode-goto-occurrence

goto-error-no-select: C-o
  occur-mode-map
    o        occur-mode-goto-occurrence-other-window
    C-o      occur-mode-display-occurrence

next-error-no-visit: M-n
  compilation-mode-map
    M-n      compilation-next-error
  diff-mode-shared-map
    M-n      diff-hunk-next
  occur-mode-map
    M-n      occur-next

previous-error-no-visit: M-p
  compilation-mode-map
    M-p      compilation-previous-error
  diff-mode-shared-map
    M-p      diff-hunk-prev
  occur-mode-map
    M-p      occur-prev

next-error-no-select: C-M-n
  grep-mode-map
    n        next-error-no-select

previous-error-no-select: C-M-p
  grep-mode-map
    p        previous-error-no-select

next-error-file-no-select: M-}, M-N
  compilation-mode-map
    M-}      compilation-next-file
  grep-mode-map
    }        compilation-next-file
    \t       compilation-next-file
  diff-mode-shared-map
    M-N      diff-file-next
    M-}      diff-file-next

previous-error-file-no-select: M-{, M-P
  compilation-mode-map
    M-{      compilation-previous-file
  grep-mode-map
    {        compilation-previous-file
  diff-mode-shared-map
    M-P      diff-file-prev
    M-{      diff-file-prev

next-error-file: new global command without keybindings
previous-error-file: new global command without keybindings


Other current keybindings which could be unified somehow as well:

compilation-mode-map
    SPC      scroll-up
    DEL      scroll-down

grep-mode-map
    SPC      scroll-up
    DEL      scroll-down

diff-mode-shared-map
    M-SPC    scroll-up
    M-DEL    scroll-down
    M-q      quit-window

occur-mode-map
    r       occur-rename-buffer
    c       clone-buffer
    g       revert-buffer
    q       quit-window
    z       kill-this-buffer

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

Re: next-error-last-buffer

[Ted Zlatanov]

On Tue, 25 May 2004, juri@jurta.org wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>> But what if the user wants the next place in the patch file?  It
>> would be very useful to have next-error support that as well.
>>
>> Maybe next-error should know when a user visits a buffer
>> interactively (with a keyboard command or a mouse click) versus
>> through a next-error invocation.  That way, the user can select the
>> diff buffer manually when they want the next diff hunk, but otherwise
>> next-error will keep using the original invocant buffer.
> 
> When users want to go to the next place in the patch file they can
> revisit it by killing a buffer and visiting it again (e.g. by C-x C-f).
> This way the variable `next-error-function' will be set again
> in that buffer.

That's really awkward.  I'd rather rewrite my code than ask the user
to work around my code like this.

Ted

Re: next-error-last-buffer

[Ted Zlatanov]

On Tue, 25 May 2004, juri@jurta.org wrote:

> Richard Stallman <rms@gnu.org> writes:
>> This fix has a drawback; it will make that buffer permanently
>> incapable of being used as a series of references to places.
>>
>> I think we should look for a way to disable this temporarily instead.
>> However, I am not sure how that would work--what would be the
>> condition on which to reenable this buffer's value of
>> next-error-function?
> 
> If there is a real need to enable next-error-function in the existing
> buffer visited by next-error (i.e. if it's not too rare case when the
> user needs to kill a buffer and create a new, that may be inconvenient
> if performed too often), then next-error-function could be enabled again
> by setting it to the initial value by typing C-m or one of other error
> visiting keys available in the next-error capable buffer.  When these
> keys are bound to one of the following functions, each function could
> set the initial value of next-error-function every time it called
> in the next-error capable buffer:
> 
> compile-goto-error
> diff-goto-source
> occur-mode-goto-occurrence

I think your proposal forces the user to do something unexpected in
the flow of their work.  It's not a terrible solution, if it's the
only one we have, but I would prefer to do it in a different way:

Maybe if there's more than one next-error capable buffers that are
linked together (e.g. occur on a diff) then C-u next-error should
advance through the "underlying" next-error buffer (the diff) while
next-error should advance through the "overlay" next-error buffer
(the occur).  If the user does a grep on an occur on a diff, for
instance, then C-u C-u next-error advances through the diff, C-u
next-error advances through the occur, and next-error advances
through the grep.

Does this approach seem useful?

Ted

Re: next-error-last-buffer

[Richard Stallman]

    When users want to go to the next place in the patch file they can
    revisit it by killing a buffer and visiting it again (e.g. by C-x C-f).
    This way the variable `next-error-function' will be set again
    in that buffer.

Sorry, I don't like that--I think it is a problem, not a solution.

    If there is a real need to enable next-error-function in the existing
    buffer visited by next-error (i.e. if it's not too rare case when the
    user needs to kill a buffer and create a new, that may be inconvenient
    if performed too often), then next-error-function could be enabled again
    by setting it to the initial value by typing C-m or one of other error
    visiting keys available in the next-error capable buffer.

That might be an ok solution.  It is worth trying, at least.

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Maybe if there's more than one next-error capable buffers that are
> linked together (e.g. occur on a diff) then C-u next-error should
> advance through the "underlying" next-error buffer (the diff) while
> next-error should advance through the "overlay" next-error buffer
> (the occur).  If the user does a grep on an occur on a diff, for
> instance, then C-u C-u next-error advances through the diff, C-u
> next-error advances through the occur, and next-error advances
> through the grep.

C-u prefix of next-error is already used to reparse the error
message buffer and start at the first error.

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

Re: next-error-last-buffer

[Richard Stallman]

    Maybe if there's more than one next-error capable buffers that are
    linked together (e.g. occur on a diff) then C-u next-error should
    advance through the "underlying" next-error buffer (the diff) while
    next-error should advance through the "overlay" next-error buffer
    (the occur).

That is a bad solution because it requires people to remember
yet another feature.  The other solution is better, because
it is more likely that the intended thing will happen
as a result of use of the other existing features.

Re: next-error-last-buffer

[Stefan Monnier]

>     Maybe if there's more than one next-error capable buffers that are
>     linked together (e.g. occur on a diff) then C-u next-error should
>     advance through the "underlying" next-error buffer (the diff) while
>     next-error should advance through the "overlay" next-error buffer
>     (the occur).

> That is a bad solution because it requires people to remember
> yet another feature.  The other solution is better, because
> it is more likely that the intended thing will happen
> as a result of use of the other existing features.

A less intrusive (and hence less complete) solution:

- Create a new compilation-last-source-buffer variable.
- At the end of next-error, set this new variable to the buffer just being
  displayed.
- at the beginning of next-error check compilation-last-source-buffer:
  if it is equal to current-buffer, then don't consider this buffer as
  a "compilation" buffer (i.e. ignore its next-error-function).

This way if a C-x ` lands us in a diff-mode buffer (because of a *grep* that
points to a patch file), a subsequent C-x ` in the same buffer will not
mistakenly step through the diffs of this buffer but will go to the next
grep match.


        Stefan

Re: next-error-last-buffer

[Ted Zlatanov]

On Thu, 27 May 2004, rms@gnu.org wrote:

>     If there is a real need to enable next-error-function in the existing
>     buffer visited by next-error (i.e. if it's not too rare case when the
>     user needs to kill a buffer and create a new, that may be inconvenient
>     if performed too often), then next-error-function could be enabled again
>     by setting it to the initial value by typing C-m or one of other error
>     visiting keys available in the next-error capable buffer.
> 
> That might be an ok solution.  It is worth trying, at least.

Let me make sure I understand the problem and solution.

When next-error is called in buffer X, it may pop the user into
buffer Y.  We want to unset next-error-function in Y, so that
next-error does not act in Y from that point on.

Couldn't this be achieved by making the next-error-last-buffer check
in next-error-find-buffer precede the current-buffer check?

We need to define a function next-error-follow-this-buffer that would
set next-error-last-buffer to (current-buffer).  That way, users can
force the behavior that now is the default, that next-error should act
on (current-buffer) first and foremost.  I would bind
next-error-follow-this-buffer to C-x ~ (which on US keyboards is
Shift-` so remembering it is not too bad).

Ted

Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Let me make sure I understand the problem and solution.
>
> When next-error is called in buffer X, it may pop the user into
> buffer Y.  We want to unset next-error-function in Y, so that
> next-error does not act in Y from that point on.

Correct.

> Couldn't this be achieved by making the next-error-last-buffer check
> in next-error-find-buffer precede the current-buffer check?

This change will solve the problem.

> We need to define a function next-error-follow-this-buffer that would
> set next-error-last-buffer to (current-buffer).  That way, users can
> force the behavior that now is the default, that next-error should act
> on (current-buffer) first and foremost.  I would bind
> next-error-follow-this-buffer to C-x ~ (which on US keyboards is
> Shift-` so remembering it is not too bad).

There is no need for an additional function and keybinding.  The action
you proposed (i.e. setting next-error-last-buffer to (current-buffer))
could be performed in location-visiting functions usually bound to C-m
and C-c C-c.

But there is even simpler solution for the user to select a buffer
for the next C-x `.

Taking into account the recent addition of a rule in
`next-error-find-buffer' which returns a buffer which is displayed
only in one window with a next-error capable buffer on the selected
frame, the user can simply remove the unwanted window with a
next-error capable buffer (e.g. *grep* buffer in the aforementioned
test case) from the selected frame and C-x ` will use the buffer from
the remaining window (e.g. a patch file) even if it is not the same as
next-error-last-buffer.

So the only change needed is to modify the rule order like you proposed,
which could look as below:

1. If one window on the selected frame displays such buffer, return it.
2. If next-error-last-buffer is set to a live buffer, use that.
3. If the current buffer is a next-error capable buffer, return it.
...

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

Re: next-error-last-buffer

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> A less intrusive (and hence less complete) solution:
>
> - Create a new compilation-last-source-buffer variable.
> - At the end of next-error, set this new variable to the buffer just being
>   displayed.
> - at the beginning of next-error check compilation-last-source-buffer:
>   if it is equal to current-buffer, then don't consider this buffer as
>   a "compilation" buffer (i.e. ignore its next-error-function).
>
> This way if a C-x ` lands us in a diff-mode buffer (because of a *grep* that
> points to a patch file), a subsequent C-x ` in the same buffer will not
> mistakenly step through the diffs of this buffer but will go to the next
> grep match.

For clarity I'd rewrite your solution as a next-error-find-buffer rule:

1. If the current next-error capable buffer is not the last source buffer.
2. If one window on the selected frame displays such buffer, return it.
3. If next-error-last-buffer is set to a live buffer, use that.
...

This will solve the problem.

Perhaps there are situations where it may not work, for example, when
the user switches the source buffers.  But it's impossible to guess
whether he switched the source buffer with the intention to start
going through the diffs or he wants to continue visiting grep results.
In the latter case, he can select the *grep* window and type C-m or C-c C-c
to go to the next grep match instead of starting to visit the diffs.

So I think your solution will produce the expected behavior.

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

Re: next-error-last-buffer

[Richard Stallman]

    goto-error: C-m, C-c C-c, M-o

Why do we want to define M-o as well as the other two?
That doesn't follow any general convention, it isn't more
convenient than C-m, and it isn't needed for compatibility.

    next-error-no-visit: M-n

Let's call that forward-error-message.

    previous-error-no-visit: M-p

Let's call that backward-error-message.

    next-error-file-no-select: M-}, M-N

I'd rather avoid defining M-N and M-P as different from M-n and M-p.
We don't need to do it; M-{ and M-} are equally easy to type.

Also, let's call these commands forward-error-source-file
and backward-error-source-file.

    next-error-file: new global command without keybindings
    previous-error-file: new global command without keybindings

What would these new commands do?

Re: next-error-last-buffer

[Ted Zlatanov]

On 28 May 2004, monnier@iro.umontreal.ca wrote:

> A less intrusive (and hence less complete) solution:
> 
> - Create a new compilation-last-source-buffer variable.
> - At the end of next-error, set this new variable to the buffer just being
> 	displayed.
> - at the beginning of next-error check compilation-last-source-buffer:
>   if it is equal to current-buffer, then don't consider this buffer as
>   a "compilation" buffer (i.e. ignore its next-error-function).
> 
> This way if a C-x ` lands us in a diff-mode buffer (because of a *grep* that
> points to a patch file), a subsequent C-x ` in the same buffer will not
> mistakenly step through the diffs of this buffer but will go to the next
> grep match.

I think my proposal to reorder the rules of next-error-find-buffer to
use next-error-last-buffer BEFORE (current-buffer) is essentially what
you are proposing.  If not, let me know.

Ted

Re: next-error-last-buffer

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Sat, 29 May 2004, juri@jurta.org wrote:

> But there is even simpler solution for the user to select a buffer
> for the next C-x `.
> 
> Taking into account the recent addition of a rule in
> `next-error-find-buffer' which returns a buffer which is displayed
> only in one window with a next-error capable buffer on the selected
> frame, the user can simply remove the unwanted window with a
> next-error capable buffer (e.g. *grep* buffer in the aforementioned
> test case) from the selected frame and C-x ` will use the buffer from
> the remaining window (e.g. a patch file) even if it is not the same as
> next-error-last-buffer.

Nice, that simplifies things a lot.

> So the only change needed is to modify the rule order like you proposed,
> which could look as below:
> 
> 1. If one window on the selected frame displays such buffer, return it.
> 2. If next-error-last-buffer is set to a live buffer, use that.
> 3. If the current buffer is a next-error capable buffer, return it.
> ...

Patch attached (unified and context).

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: simple.patch --]
[-- Type: text/x-patch, Size: 2815 bytes --]

--- lisp/simple.el	2004-05-29 23:02:38.000000000 -0400
+++ /home/tzz/emacs/mine/simple.el	2004-05-29 23:04:45.000000000 -0400
@@ -92,33 +92,34 @@
 	next-error-function)))
 
 ;; Return a next-error capable buffer according to the following rules:
-;; 1. If the current buffer is a next-error capable buffer, return it.
-;; 2. If one window on the selected frame displays such buffer, return it.
-;; 3. If next-error-last-buffer is set to a live buffer, use that.
+;; 1. If next-error-last-buffer is set to a live buffer, use that.
+;; 2. If the current buffer is a next-error capable buffer, return it.
+;; 3. If one window on the selected frame displays such buffer, return it.
 ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
 ;; 5. Signal an error if there are none.
 (defun next-error-find-buffer (&optional other-buffer extra-test)
-  (if (and (not other-buffer)
-	   (next-error-buffer-p (current-buffer) extra-test))
-      ;; The current buffer is a next-error capable buffer.
-      (current-buffer)
-    (or
-     (let ((window-buffers
-            (delete-dups
-             (delq nil
-              (mapcar (lambda (w)
-                        (and (next-error-buffer-p (window-buffer w) extra-test)
-                             (window-buffer w)))
-                      (window-list))))))
-       (if other-buffer
-           (setq window-buffers (delq (current-buffer) window-buffers)))
-       (if (eq (length window-buffers) 1)
-           (car window-buffers)))
-     (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
-              (next-error-buffer-p next-error-last-buffer extra-test)
-              (or (not other-buffer) (not (eq next-error-last-buffer
-                                              (current-buffer)))))
-         next-error-last-buffer
+  (if (and next-error-last-buffer 
+	   (buffer-name next-error-last-buffer)
+	   (next-error-buffer-p next-error-last-buffer extra-test)
+	   (or (not other-buffer) 
+	       (not (eq next-error-last-buffer (current-buffer)))))
+      next-error-last-buffer
+    (if (and (not other-buffer)
+	     (next-error-buffer-p (current-buffer) extra-test))
+	;; The current buffer is a next-error capable buffer.
+	(current-buffer)
+      (or
+       (let ((window-buffers
+	      (delete-dups
+	       (delq nil
+		     (mapcar (lambda (w)
+			       (and (next-error-buffer-p (window-buffer w) extra-test)
+				    (window-buffer w)))
+			     (window-list))))))
+	 (if other-buffer
+	     (setq window-buffers (delq (current-buffer) window-buffers)))
+	 (if (eq (length window-buffers) 1)
+	     (car window-buffers)))
        (let ((buffers (buffer-list)))
          (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                  (and other-buffer

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: simple.context.patch --]
[-- Type: text/x-patch, Size: 3348 bytes --]

*** lisp/simple.el	Sat May 29 23:02:38 2004
--- /home/tzz/emacs/mine/simple.el	Sat May 29 23:04:45 2004
***************
*** 92,124 ****
  	next-error-function)))
  
  ;; Return a next-error capable buffer according to the following rules:
! ;; 1. If the current buffer is a next-error capable buffer, return it.
! ;; 2. If one window on the selected frame displays such buffer, return it.
! ;; 3. If next-error-last-buffer is set to a live buffer, use that.
  ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
  ;; 5. Signal an error if there are none.
  (defun next-error-find-buffer (&optional other-buffer extra-test)
!   (if (and (not other-buffer)
! 	   (next-error-buffer-p (current-buffer) extra-test))
!       ;; The current buffer is a next-error capable buffer.
!       (current-buffer)
!     (or
!      (let ((window-buffers
!             (delete-dups
!              (delq nil
!               (mapcar (lambda (w)
!                         (and (next-error-buffer-p (window-buffer w) extra-test)
!                              (window-buffer w)))
!                       (window-list))))))
!        (if other-buffer
!            (setq window-buffers (delq (current-buffer) window-buffers)))
!        (if (eq (length window-buffers) 1)
!            (car window-buffers)))
!      (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
!               (next-error-buffer-p next-error-last-buffer extra-test)
!               (or (not other-buffer) (not (eq next-error-last-buffer
!                                               (current-buffer)))))
!          next-error-last-buffer
         (let ((buffers (buffer-list)))
           (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                   (and other-buffer
--- 92,125 ----
  	next-error-function)))
  
  ;; Return a next-error capable buffer according to the following rules:
! ;; 1. If next-error-last-buffer is set to a live buffer, use that.
! ;; 2. If the current buffer is a next-error capable buffer, return it.
! ;; 3. If one window on the selected frame displays such buffer, return it.
  ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
  ;; 5. Signal an error if there are none.
  (defun next-error-find-buffer (&optional other-buffer extra-test)
!   (if (and next-error-last-buffer 
! 	   (buffer-name next-error-last-buffer)
! 	   (next-error-buffer-p next-error-last-buffer extra-test)
! 	   (or (not other-buffer) 
! 	       (not (eq next-error-last-buffer (current-buffer)))))
!       next-error-last-buffer
!     (if (and (not other-buffer)
! 	     (next-error-buffer-p (current-buffer) extra-test))
! 	;; The current buffer is a next-error capable buffer.
! 	(current-buffer)
!       (or
!        (let ((window-buffers
! 	      (delete-dups
! 	       (delq nil
! 		     (mapcar (lambda (w)
! 			       (and (next-error-buffer-p (window-buffer w) extra-test)
! 				    (window-buffer w)))
! 			     (window-list))))))
! 	 (if other-buffer
! 	     (setq window-buffers (delq (current-buffer) window-buffers)))
! 	 (if (eq (length window-buffers) 1)
! 	     (car window-buffers)))
         (let ((buffers (buffer-list)))
           (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                   (and other-buffer

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: next-error-last-buffer

[Richard Stallman]

    A less intrusive (and hence less complete) solution:

    - Create a new compilation-last-source-buffer variable.
    - At the end of next-error, set this new variable to the buffer just being
      displayed.
    - at the beginning of next-error check compilation-last-source-buffer:
      if it is equal to current-buffer, then don't consider this buffer as
      a "compilation" buffer (i.e. ignore its next-error-function).

This might be good.  We can at least try it.

Re: next-error-last-buffer

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I'd rather avoid defining M-N and M-P as different from M-n and M-p.
> We don't need to do it; M-{ and M-} are equally easy to type.

Not on a danish keyboard ...

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

Re: next-error-last-buffer

[Richard Stallman]

    > So the only change needed is to modify the rule order like you proposed,
    > which could look as below:
    > 
    > 1. If one window on the selected frame displays such buffer, return it.
    > 2. If next-error-last-buffer is set to a live buffer, use that.
    > 3. If the current buffer is a next-error capable buffer, return it.
    > ...

That might solve the problem, but what you have written is very
different:

    +;; 1. If next-error-last-buffer is set to a live buffer, use that.
    +;; 2. If the current buffer is a next-error capable buffer, return it.
    +;; 3. If one window on the selected frame displays such buffer, return it.
     ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
     ;; 5. Signal an error if there are none.

This change has the unpleasant side effect of eliminating any
convenient way to control which buffer you want to take errors from.
next-error-last-buffer takes precedence over everything else,
so there is no way to deliberately override it.

Using the current buffer is wrong only in one special case: where that
buffer was found as the source locus for an error.  In all other
cases, it is right to use the current buffer rather than
next-error-last-buffer.

Re: next-error-last-buffer

[Richard Stallman]

    > I'd rather avoid defining M-N and M-P as different from M-n and M-p.
    > We don't need to do it; M-{ and M-} are equally easy to type.

    Not on a danish keyboard ...

Sorry, I don't want to design key bindings for the sake of the danish
keyboard.

Re: next-error-last-buffer

[Werner LEMBERG]

>     > I'd rather avoid defining M-N and M-P as different from M-n
>     > and M-p.  We don't need to do it; M-{ and M-} are equally easy
>     > to type.
> 
>     Not on a danish keyboard ...
> 
> Sorry, I don't want to design key bindings for the sake of the
> danish keyboard.

Well, it is problematic on a German keyboard too...  I agree that it
doesn't make sense to take care of language-specific keyboard layouts,
but I think it is not optimal to completely ignore this fact.


    Werner

Re: next-error-last-buffer

[Juanma Barranquero]

On Mon, 31 May 2004 08:39:02 +0200 (CEST)
Werner LEMBERG <wl@gnu.org> wrote:

> Well, it is problematic on a German keyboard too...

And on a Spanish one.

  M-{  <ESC> Alt-Gr ´
  M-}  <ESC> Alt-Gr ç  

That's two-hand, three-finger combinations :)

                                                                Juanma

Re: next-error-last-buffer

[Ted Zlatanov]

On Sun, 30 May 2004, rms@gnu.org wrote:

    >> So the only change needed is to modify the rule order like you proposed,
>     > which could look as below:
>     > 
>     > 1. If one window on the selected frame displays such buffer, return it.
>     > 2. If next-error-last-buffer is set to a live buffer, use that.
>     > 3. If the current buffer is a next-error capable buffer, return it.
>     > ...
> 
> That might solve the problem, but what you have written is very
> different:

[...]

> This change has the unpleasant side effect of eliminating any
> convenient way to control which buffer you want to take errors from.
> next-error-last-buffer takes precedence over everything else,
> so there is no way to deliberately override it.

Sorry.  Consider the attached patch, which does the right thing (the
first 3 rules you quoted from Juri's e-mail are implemented).

Overriding the selection of the next-error buffer is easily done with
C-x 1 or C-x 0 as appropriate, to make the one buffer of interest the
only buffer displayed.

> Using the current buffer is wrong only in one special case: where that
> buffer was found as the source locus for an error.  In all other
> cases, it is right to use the current buffer rather than
> next-error-last-buffer.

Yes, but "source locus for an error" is not easy to track - I pointed
out that it's conceivable that a user might do grep on occur on
compile; there's a lot of marginal cases that I'm not sure we have to
anticipate.  I think a simple algorithm, as stated above, is the
right way to approach the problem right now - and if not, we can
certainly change the algorithm as needed.

Ted

Re: next-error-last-buffer

[Ted Zlatanov]

On Fri, 28 May 2004, rms@gnu.org wrote:

>     next-error-no-visit: M-n
> 
> Let's call that forward-error-message.
> 
>     previous-error-no-visit: M-p
> 
> Let's call that backward-error-message.

Wouldn't that be confusing?  We already have the prefixing adjectives
"next" and "previous" established, now users have to also remember
"forward" and "backward."  I know Emacs already does it in many
places, but I think we should try to limit the number of adjectives
in this case.

>     next-error-file-no-select: M-}, M-N
> 
> I'd rather avoid defining M-N and M-P as different from M-n and M-p.
> We don't need to do it; M-{ and M-} are equally easy to type.
> 
> Also, let's call these commands forward-error-source-file
> and backward-error-source-file.

Ditto as above.

Thanks
Ted

Re: next-error-last-buffer

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

On Tue, 01 Jun 2004, tzz@lifelogs.com wrote:

> Sorry.  Consider the attached patch, which does the right thing (the
> first 3 rules you quoted from Juri's e-mail are implemented).

Yes, the patch would be nice too :)

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: simple.patch --]
[-- Type: text/x-patch, Size: 2415 bytes --]

95,97c95,97
< ;; 1. If the current buffer is a next-error capable buffer, return it.
< ;; 2. If one window on the selected frame displays such buffer, return it.
< ;; 3. If next-error-last-buffer is set to a live buffer, use that.
---
> ;; 1. If one window on the selected frame displays such buffer, return it.
> ;; 2. If next-error-last-buffer is set to a live buffer, use that.
> ;; 3. If the current buffer is a next-error capable buffer, return it.
101,121c101,122
<   (if (and (not other-buffer)
< 	   (next-error-buffer-p (current-buffer) extra-test))
<       ;; The current buffer is a next-error capable buffer.
<       (current-buffer)
<     (or
<      (let ((window-buffers
<             (delete-dups
<              (delq nil
<               (mapcar (lambda (w)
<                         (and (next-error-buffer-p (window-buffer w) extra-test)
<                              (window-buffer w)))
<                       (window-list))))))
<        (if other-buffer
<            (setq window-buffers (delq (current-buffer) window-buffers)))
<        (if (eq (length window-buffers) 1)
<            (car window-buffers)))
<      (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
<               (next-error-buffer-p next-error-last-buffer extra-test)
<               (or (not other-buffer) (not (eq next-error-last-buffer
<                                               (current-buffer)))))
<          next-error-last-buffer
---
>   (or
>    (let ((window-buffers
> 	  (delete-dups
> 	   (delq nil
> 		 (mapcar (lambda (w)
> 			   (and (next-error-buffer-p (window-buffer w) extra-test)
> 				(window-buffer w)))
> 			 (window-list))))))
>      (if other-buffer
> 	 (setq window-buffers (delq (current-buffer) window-buffers)))
>      (if (eq (length window-buffers) 1)
> 	 (car window-buffers)))
>    (if (and next-error-last-buffer 
> 	    (buffer-name next-error-last-buffer)
> 	    (next-error-buffer-p next-error-last-buffer extra-test)
> 	    (or (not other-buffer) 
> 		(not (eq next-error-last-buffer (current-buffer)))))
>        next-error-last-buffer
>      (if (and (not other-buffer)
> 	      (next-error-buffer-p (current-buffer) extra-test))
> 	 ;; The current buffer is a next-error capable buffer.
> 	 (current-buffer))))
136c137
<                (error "No next-error capable buffer found!"))))))))
---
>                (error "No next-error capable buffer found!")))))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: simple.context.patch --]
[-- Type: text/x-patch, Size: 4067 bytes --]

*** lisp/simple.el	Tue Jun  1 13:35:21 2004
--- /home/tzz/emacs/mine/simple.el	Tue Jun  1 13:53:43 2004
***************
*** 92,124 ****
  	next-error-function)))
  
  ;; Return a next-error capable buffer according to the following rules:
! ;; 1. If the current buffer is a next-error capable buffer, return it.
! ;; 2. If one window on the selected frame displays such buffer, return it.
! ;; 3. If next-error-last-buffer is set to a live buffer, use that.
  ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
  ;; 5. Signal an error if there are none.
  (defun next-error-find-buffer (&optional other-buffer extra-test)
!   (if (and (not other-buffer)
! 	   (next-error-buffer-p (current-buffer) extra-test))
!       ;; The current buffer is a next-error capable buffer.
!       (current-buffer)
!     (or
!      (let ((window-buffers
!             (delete-dups
!              (delq nil
!               (mapcar (lambda (w)
!                         (and (next-error-buffer-p (window-buffer w) extra-test)
!                              (window-buffer w)))
!                       (window-list))))))
!        (if other-buffer
!            (setq window-buffers (delq (current-buffer) window-buffers)))
!        (if (eq (length window-buffers) 1)
!            (car window-buffers)))
!      (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
!               (next-error-buffer-p next-error-last-buffer extra-test)
!               (or (not other-buffer) (not (eq next-error-last-buffer
!                                               (current-buffer)))))
!          next-error-last-buffer
         (let ((buffers (buffer-list)))
           (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                   (and other-buffer
--- 92,125 ----
  	next-error-function)))
  
  ;; Return a next-error capable buffer according to the following rules:
! ;; 1. If one window on the selected frame displays such buffer, return it.
! ;; 2. If next-error-last-buffer is set to a live buffer, use that.
! ;; 3. If the current buffer is a next-error capable buffer, return it.
  ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
  ;; 5. Signal an error if there are none.
  (defun next-error-find-buffer (&optional other-buffer extra-test)
!   (or
!    (let ((window-buffers
! 	  (delete-dups
! 	   (delq nil
! 		 (mapcar (lambda (w)
! 			   (and (next-error-buffer-p (window-buffer w) extra-test)
! 				(window-buffer w)))
! 			 (window-list))))))
!      (if other-buffer
! 	 (setq window-buffers (delq (current-buffer) window-buffers)))
!      (if (eq (length window-buffers) 1)
! 	 (car window-buffers)))
!    (if (and next-error-last-buffer 
! 	    (buffer-name next-error-last-buffer)
! 	    (next-error-buffer-p next-error-last-buffer extra-test)
! 	    (or (not other-buffer) 
! 		(not (eq next-error-last-buffer (current-buffer)))))
!        next-error-last-buffer
!      (if (and (not other-buffer)
! 	      (next-error-buffer-p (current-buffer) extra-test))
! 	 ;; The current buffer is a next-error capable buffer.
! 	 (current-buffer))))
         (let ((buffers (buffer-list)))
           (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                   (and other-buffer
***************
*** 133,139 ****
                        (if other-buffer
                            (message "This is the only next-error capable buffer."))
                        (current-buffer)))
!                (error "No next-error capable buffer found!"))))))))
  
  (defun next-error (arg &optional reset)
    "Visit next next-error message and corresponding source code.
--- 134,140 ----
                        (if other-buffer
                            (message "This is the only next-error capable buffer."))
                        (current-buffer)))
!                (error "No next-error capable buffer found!")))))
  
  (defun next-error (arg &optional reset)
    "Visit next next-error message and corresponding source code.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: next-error-last-buffer

[Kim F. Storm]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 28 May 2004, rms@gnu.org wrote:
> 
> >     next-error-no-visit: M-n
> > 
> > Let's call that forward-error-message.
> > 
> >     previous-error-no-visit: M-p
> > 
> > Let's call that backward-error-message.
> 
> Wouldn't that be confusing?  We already have the prefixing adjectives
> "next" and "previous" established, now users have to also remember
> "forward" and "backward."  I know Emacs already does it in many
> places, but I think we should try to limit the number of adjectives
> in this case.

I also find the forward-/backward- prefixes inappropriate in this
case; to me they indicate movement in the current buffer or some
other "closed context".

In contrast, the next-/previous- doesn't necessarily indicate any
specific sequence of the visited items (navigating in a list of
places to visit).

> 
> >     next-error-file-no-select: M-}, M-N
> > 
> > I'd rather avoid defining M-N and M-P as different from M-n and M-p.
> > We don't need to do it; M-{ and M-} are equally easy to type.
> > 
> > Also, let's call these commands forward-error-source-file
> > and backward-error-source-file.
> 
> Ditto as above.
> 

Ditto.

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

Re: next-error-last-buffer

[Richard Stallman]

    >     next-error-no-visit: M-n
    > 
    > Let's call that forward-error-message.
    > 
    >     previous-error-no-visit: M-p
    > 
    > Let's call that backward-error-message.

    Wouldn't that be confusing?  We already have the prefixing adjectives
    "next" and "previous" established, now users have to also remember
    "forward" and "backward."

I think people will understand them.  These names follow tradition,
make sense, and are clean; the others are clumsy.

    I also find the forward-/backward- prefixes inappropriate in this
    case; to me they indicate movement in the current buffer or some
    other "closed context".

That's exactly what these commands are: they move forward and back in
the current buffer, moving by error messages.  Here's what they were
proposed to replace:

    next-error-no-visit: M-n
      compilation-mode-map
	M-n      compilation-next-error
      diff-mode-shared-map
	M-n      diff-hunk-next
      occur-mode-map
	M-n      occur-next

Re: next-error-last-buffer

[Richard Stallman]

This version of the patch looks right.
Could you look for what documentation needs changing for this?
We should install the documentation change at the same time.

Re: next-error-last-buffer

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Wed, 02 Jun 2004, rms@gnu.org wrote:

> This version of the [next-error-find-buffer] patch looks right.

Great.

> Could you look for what documentation needs changing for this?
> We should install the documentation change at the same time.

The only docs for next-error are in the function declaration; I fixed
those and the new patch is attached.

Everything else in the docs (I grepped for references) says nothing
about the order of buffer discovery.

If you mean that documentation for the next-error framework is
needed, that's another issue :)

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: simple.context.patch --]
[-- Type: text/x-patch, Size: 2812 bytes --]

95,97c95,97
< ;; 1. If the current buffer is a next-error capable buffer, return it.
< ;; 2. If one window on the selected frame displays such buffer, return it.
< ;; 3. If next-error-last-buffer is set to a live buffer, use that.
---
> ;; 1. If one window on the selected frame displays such buffer, return it.
> ;; 2. If next-error-last-buffer is set to a live buffer, use that.
> ;; 3. If the current buffer is a next-error capable buffer, return it.
101,121c101,122
<   (if (and (not other-buffer)
< 	   (next-error-buffer-p (current-buffer) extra-test))
<       ;; The current buffer is a next-error capable buffer.
<       (current-buffer)
<     (or
<      (let ((window-buffers
<             (delete-dups
<              (delq nil
<               (mapcar (lambda (w)
<                         (and (next-error-buffer-p (window-buffer w) extra-test)
<                              (window-buffer w)))
<                       (window-list))))))
<        (if other-buffer
<            (setq window-buffers (delq (current-buffer) window-buffers)))
<        (if (eq (length window-buffers) 1)
<            (car window-buffers)))
<      (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
<               (next-error-buffer-p next-error-last-buffer extra-test)
<               (or (not other-buffer) (not (eq next-error-last-buffer
<                                               (current-buffer)))))
<          next-error-last-buffer
---
>   (or
>    (let ((window-buffers
> 	  (delete-dups
> 	   (delq nil
> 		 (mapcar (lambda (w)
> 			   (and (next-error-buffer-p (window-buffer w) extra-test)
> 				(window-buffer w)))
> 			 (window-list))))))
>      (if other-buffer
> 	 (setq window-buffers (delq (current-buffer) window-buffers)))
>      (if (eq (length window-buffers) 1)
> 	 (car window-buffers)))
>    (if (and next-error-last-buffer 
> 	    (buffer-name next-error-last-buffer)
> 	    (next-error-buffer-p next-error-last-buffer extra-test)
> 	    (or (not other-buffer) 
> 		(not (eq next-error-last-buffer (current-buffer)))))
>        next-error-last-buffer
>      (if (and (not other-buffer)
> 	      (next-error-buffer-p (current-buffer) extra-test))
> 	 ;; The current buffer is a next-error capable buffer.
> 	 (current-buffer))))
136c137
<                (error "No next-error capable buffer found!"))))))))
---
>                (error "No next-error capable buffer found!")))))
156,158c157,160
< `next-error-function' is bound to an appropriate
< function.  To specify use of a particular buffer for error
< messages, type \\[next-error] in that buffer.
---
> `next-error-function' is bound to an appropriate function.  To
> specify use of a particular buffer for error messages, type
> \\[next-error] in that buffer when it is the only one displayed
> in the current frame.

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: next-error-last-buffer

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     goto-error: C-m, C-c C-c, M-o
>
> Why do we want to define M-o as well as the other two?
> That doesn't follow any general convention, it isn't more
> convenient than C-m, and it isn't needed for compatibility.

Occur mode binds "o" to `occur-mode-goto-occurrence-other-window' and
diff mode binds "o" to `diff-goto-source'.  But since "o" should insert
the ?o character in other modes, I added "M-" key prefix.  Though,
M-o is not needed too much.

>     next-error-no-visit: M-n
>
> Let's call that forward-error-message.
>
>     previous-error-no-visit: M-p
>
> Let's call that backward-error-message.

So as I understand, a general convention would be using forward-/backward-
prefix for commands that move the point only in the current compile/grep/...
buffer, and next-/previous- for commands which are invoked in the
source buffers.  It would be good if this convention will be followed
for all function names.

>     next-error-file-no-select: M-}, M-N
>
> I'd rather avoid defining M-N and M-P as different from M-n and M-p.
> We don't need to do it; M-{ and M-} are equally easy to type.

They are not easy to type on most European keyboards, so alternative
keybindings couldn't hurt.

BTW, C-x ` is not easy to type on these keyboards too.  There could be
an alternative keybinding.

> Also, let's call these commands forward-error-source-file
> and backward-error-source-file.
>
>     next-error-file: new global command without keybindings
>     previous-error-file: new global command without keybindings
>
> What would these new commands do?

These commands would do the same what `forward-error-source-file' and 
backward-error-source-file' will do in the current compilation buffer.
But `next-error-file' and `previous-error-file' will be called
from the source buffers, like `next-error' and `previous-error',
and will visit the next file instead of the next error.

Actually, instead of adding these new commands it would be better
if `next-error' interpreted a special prefix argument with the
meaning to skip to the next file.  But it seems all possible prefix
arguments of C-x ` are already used.

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

Re: next-error-last-buffer

[Richard Stallman]

    The only docs for next-error are in the function declaration; I fixed
    those and the new patch is attached.

I am sure next-error is documented in the Emacs Manual.

    Everything else in the docs (I grepped for references) says nothing
    about the order of buffer discovery.

I think we need to document that in the Emacs Manual.
We also need to update the parts about Occur.

Re: next-error-last-buffer

[Richard Stallman]

    Occur mode binds "o" to `occur-mode-goto-occurrence-other-window' and
    diff mode binds "o" to `diff-goto-source'.  But since "o" should insert
    the ?o character in other modes, I added "M-" key prefix.  Though,
    M-o is not needed too much.

I would rather not use up another binding for this.  Please leave it out.

    So as I understand, a general convention would be using forward-/backward-
    prefix for commands that move the point only in the current compile/grep/...
    buffer, and next-/previous- for commands which are invoked in the
    source buffers.

I did not go that far.  What I said is that the names
forward-/backward- are elsewhere used normally for commands that move
within the buffer.  In fact, so are the names next- and previous-.  In
this case, we are already using next- and previous- in a nonstandard
way, but that's no obstacle to using forward-/backward- in the
standard way here.

Using such names here is better than the available alternatives, so
let's use them.

Re: next-error-last-buffer

[Ted Zlatanov]

On Thu, 03 Jun 2004, rms@gnu.org wrote:

    > The only docs for next-error are in the function declaration; I fixed
>     those and the new patch is attached.
> 
> I am sure next-error is documented in the Emacs Manual.

OK, I found it.  The current docs are correct regarding
compilation-minor-mode, but they say nothing about the selection of
the buffer.

> I think we need to document that in the Emacs Manual.  We also need
> to update the parts about Occur.

I understand.  The compilation-minor-mode discussion, however, is not
the place for the occur next-error discussion.  Because of the way
next-error crosses modes right now, it may be better off in its own
section, referenced by the compilation-minor-mode and occur
sections.  This depends on how RMS and others feel about my proposal
for making next-error a next-DWIM interface; if next-error stays
limited then it may not deserve its own section so much.

Ted

Re: next-error-last-buffer

[Richard Stallman]

      Because of the way
    next-error crosses modes right now, it may be better off in its own
    section, referenced by the compilation-minor-mode and occur
    sections.

This is largely a matter of which way produces the most clear and
readable manual.  One has to try various methods and see which one
can be made to work best.

	       This depends on how RMS and others feel about my proposal
    for making next-error a next-DWIM interface;

As I explained, I think that is probably a bad idea.
In any case, we don't want to do it for the coming release.
So the coming release needs a manual updated for the current
state of the functionality.

Re: next-error-last-buffer

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On Tue, 08 Jun 2004, rms@gnu.org wrote:

> So the coming release needs a manual updated for the current
> state of the functionality.

I am attaching the simple.el and building.texi patches that add the
explanations needed for the new state of things.

I believe that from the user's viewpoint the building.texi
modifications are all that's needed right now, except that maybe the
Occur documentation should be modified to indicate it can use
next-error.  I made a small mention of the next-error functionality.
I am attaching a trivial patch of search.texi in addition to the two
above.

I made other changes based on a note from Juri Linkov and Jason
Rumney.  Now, next-error and all associated interactive functions
don't require an argument.  I *think* this gives us the right effect
(it did for me) but please test it if you can.

If this patch is OK I can add the ChangeLog entries appropriate.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: next-error.patch --]
[-- Type: text/x-patch, Size: 7293 bytes --]

--- /usr/src/emacs/lisp/simple.el	2004-06-30 14:03:13.000000000 -0400
+++ /home/tzz/emacs/mine/simple.el	2004-06-30 14:49:04.000000000 -0400
@@ -92,33 +92,34 @@
 	next-error-function)))
 
 ;; Return a next-error capable buffer according to the following rules:
-;; 1. If the current buffer is a next-error capable buffer, return it.
-;; 2. If one window on the selected frame displays such buffer, return it.
-;; 3. If next-error-last-buffer is set to a live buffer, use that.
+;; 1. If one window on the selected frame displays such buffer, return it.
+;; 2. If next-error-last-buffer is set to a live buffer, use that.
+;; 3. If the current buffer is a next-error capable buffer, return it.
 ;; 4. Otherwise, look for a next-error capable buffer in a buffer list.
 ;; 5. Signal an error if there are none.
 (defun next-error-find-buffer (&optional other-buffer extra-test)
-  (if (and (not other-buffer)
-	   (next-error-buffer-p (current-buffer) extra-test))
-      ;; The current buffer is a next-error capable buffer.
-      (current-buffer)
-    (or
-     (let ((window-buffers
-            (delete-dups
-             (delq nil
-              (mapcar (lambda (w)
-                        (and (next-error-buffer-p (window-buffer w) extra-test)
-                             (window-buffer w)))
-                      (window-list))))))
-       (if other-buffer
-           (setq window-buffers (delq (current-buffer) window-buffers)))
-       (if (eq (length window-buffers) 1)
-           (car window-buffers)))
-     (if (and next-error-last-buffer (buffer-name next-error-last-buffer)
-              (next-error-buffer-p next-error-last-buffer extra-test)
-              (or (not other-buffer) (not (eq next-error-last-buffer
-                                              (current-buffer)))))
-         next-error-last-buffer
+  (or
+   (let ((window-buffers
+	  (delete-dups
+	   (delq nil
+		 (mapcar (lambda (w)
+			   (and (next-error-buffer-p (window-buffer w) extra-test)
+				(window-buffer w)))
+			 (window-list))))))
+     (if other-buffer
+	 (setq window-buffers (delq (current-buffer) window-buffers)))
+     (if (eq (length window-buffers) 1)
+	 (car window-buffers)))
+   (if (and next-error-last-buffer 
+	    (buffer-name next-error-last-buffer)
+	    (next-error-buffer-p next-error-last-buffer extra-test)
+	    (or (not other-buffer) 
+		(not (eq next-error-last-buffer (current-buffer)))))
+       next-error-last-buffer
+     (if (and (not other-buffer)
+	      (next-error-buffer-p (current-buffer) extra-test))
+	 ;; The current buffer is a next-error capable buffer.
+	 (current-buffer))))
        (let ((buffers (buffer-list)))
          (while (and buffers (or (not (next-error-buffer-p (car buffers) extra-test))
                                  (and other-buffer
@@ -133,9 +134,9 @@
                       (if other-buffer
                           (message "This is the only next-error capable buffer."))
                       (current-buffer)))
-               (error "No next-error capable buffer found"))))))))
+               (error "No next-error capable buffer found!")))))
 
-(defun next-error (arg &optional reset)
+(defun next-error (&optional arg reset)
   "Visit next next-error message and corresponding source code.
 
 If all the error messages parsed so far have been processed already,
@@ -153,9 +154,10 @@
 buffer with output from the \\[compile], \\[grep] commands, or,
 more generally, on any buffer in Compilation mode or with
 Compilation Minor mode enabled, or any buffer in which
-`next-error-function' is bound to an appropriate
-function.  To specify use of a particular buffer for error
-messages, type \\[next-error] in that buffer.
+`next-error-function' is bound to an appropriate function.  To
+specify use of a particular buffer for error messages, type
+\\[next-error] in that buffer when it is the only one displayed
+in the current frame.
 
 Once \\[next-error] has chosen the buffer for error messages,
 it stays with that buffer until you use it in some other buffer which
@@ -164,7 +166,9 @@
 See variables `compilation-parse-errors-function' and
 \`compilation-error-regexp-alist' for customization ideas."
   (interactive "P")
-  (if (consp arg) (setq reset t arg nil))
+  (if (consp arg) 
+      (setq reset t 
+	    arg nil))
   (when (setq next-error-last-buffer (next-error-find-buffer))
     ;; we know here that next-error-function is a valid symbol we can funcall
     (with-current-buffer next-error-last-buffer
@@ -175,7 +179,7 @@
 
 (define-key ctl-x-map "`" 'next-error)
 
-(defun previous-error (n)
+(defun previous-error (&optional n)
   "Visit previous next-error message and corresponding source code.
 
 Prefix arg N says how many error messages to move backwards (or
@@ -183,9 +187,11 @@
 
 This operates on the output from the \\[compile] and \\[grep] commands."
   (interactive "p")
-  (next-error (- n)))
+  (if n
+      (next-error (- n))
+    (next-error)))
 
-(defun first-error (n)
+(defun first-error (&optional n)
   "Restart at the first error.
 Visit corresponding source code.
 With prefix arg N, visit the source code of the Nth error.
@@ -193,7 +199,7 @@
   (interactive "p")
   (next-error n t))
 
-(defun next-error-no-select (n)
+(defun next-error-no-select (&optional n)
   "Move point to the next error in the next-error buffer and highlight match.
 Prefix arg N says how many error messages to move forwards (or
 backwards, if negative).
@@ -203,14 +209,16 @@
   (next-error n)
   (pop-to-buffer next-error-last-buffer))
 
-(defun previous-error-no-select (n)
+(defun previous-error-no-select (&optional n)
   "Move point to the previous error in the next-error buffer and highlight match.
 Prefix arg N says how many error messages to move backwards (or
 forwards, if negative).
 Finds and highlights the source line like \\[previous-error], but does not
 select the source buffer."
   (interactive "p")
-  (next-error-no-select (- n)))
+  (if n
+      (next-error-no-select (- n))
+    (next-error-no-select)))
 
 ;;;
 
--- /usr/src/emacs/man/search.texi	2004-06-30 14:16:13.000000000 -0400
+++ /home/tzz/emacs/mine/search.texi	2004-06-30 14:34:40.000000000 -0400
@@ -1268,6 +1268,9 @@
 @kbd{o} and @kbd{C-o} display the match in another window; @kbd{C-o}
 does not select it.
 
+Occur mode supports the @code{next-error} functionality, described in
+the section on Compilation.
+
 @item M-x list-matching-lines
 Synonym for @kbd{M-x occur}.
 
--- /usr/src/emacs/man/building.texi	2004-06-30 14:03:29.000000000 -0400
+++ /home/tzz/emacs/mine/building.texi	2004-06-30 14:52:02.000000000 -0400
@@ -204,6 +204,14 @@
 buffer and finds no more error messages to visit, it fails and signals
 an Emacs error.
 
+  You don't have to be in the compilation buffer in order to use
+@code{next-error}.  If one window on the selected frame can be the
+target of the @code{next-error} call, it is used.  Else, if a buffer
+previously had @code{next-error} called on it, it is used.  Else,
+if the current buffer can be the target of @code{next-error}, it is
+used.  Else, all the buffers Emacs manages are tried for
+@code{next-error} support.
+
   @kbd{C-u C-x `} starts scanning from the beginning of the compilation
 buffer.  This is one way to process the same set of errors again.
 

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: next-error-last-buffer

[Richard Stallman]

I'd appreciate it if someone would install your changes.
I will work on the manual text for improved readability
after it is checked in.