[Top][All Lists]

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

Re: Add M-x occur to the menu-bar

From: Kim F. Storm
Subject: Re: Add M-x occur to the menu-bar
Date: 05 Feb 2004 00:20:20 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Ted Zlatanov <address@hidden> writes:

> On Fri, 30 Jan 2004, address@hidden wrote:
> I'm sure the code needs corrections, so feel free to critique.  The
> diff should have been done at the same, level too...  It should be
> enough to get the idea across.

Maybe a more generic approach could be used:

Let compile.el define a buffer-local compilation-next-error-function
variable (default value nil) which can be bound in the *occur* buffer
to #'occur-next (or whatever).

Then (the original) next-error function is modified to do this:

  (setq compilation-last-buffer (compilation-find-buffer))
  (if (buffer-local-value 'compilation-next-error-function 
      (funcall compilation-next-error-function argp)
    ... do what next-error used to do ... )

With this approach, compile.el doesn't need to know anything about
occur mode, and future similar modes can hook themselves into
next-error without modifying compile.el any further.

With this change, occur need to set compilation-last-buffer to the
*occur* buffer and bind compilation-next-error-function in that buffer
to #'occur-next. 

BTW, here are some comments on your patch:

> If occur has not been loaded at all (checked by soft-intern of
> "occur-last-buffer") next-error behaves exactly as before, looking at
> grep and compile output.

IMO, it would be cleaner to add (provide 'occur) to replace.el and just
test with (featurep 'occur).

You can then add (defvar occur-last-buffer) to compile.el to avoid
byte-compiler warnings.

The autoload of occur-next should be done as an autoload cookie in occur.el
But I don't see why do you need it at all?

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

reply via email to

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