emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: next-error-last-buffer


From: Ted Zlatanov
Subject: Re: next-error-last-buffer
Date: Wed, 12 May 2004 09:50:34 -0400
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

On Wed, 12 May 2004, address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]