emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: Add M-x occur to the menu-bar
Date: 12 Feb 2004 15:57:25 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> I think Kim suggested that.  It's so that multiple modes can set
> compilation-next-error-function without using make-local-variable.  If
> you change it, you're just pushing that work to the modes that use
> this interface.  I think it's 6 one way, half-dozen the other, so
> whatever the Emacs developers prefer is fine with me.

I think the general feling I got over the years is that
make-local-variable should generally be preferred over
make-variable-buffer-local.  For exemple the elisp manual says:

     The time to use `make-variable-buffer-local' is when it is crucial
     that no two buffers ever share the same binding.  For example,
     when a variable is used for internal purposes in a Lisp program
     which depends on having separate values in separate buffers, then
     using `make-variable-buffer-local' can be the best solution.

One of the classic pitfalls of make-variable-buffer-local which your code
suffers from is the following:
Say I change diff-mode to do

   (setq compilation-next-error-function 'diff-foo)

just like I intend to.  Now the behavior will be either to set the local or
the global vriable depending on whether or not compile.el has already
been loaded.  And no: requiring compile.el is not an acceptable option.

>> Also why not rename next-error to compilation-next-error, then
>> default compilation-next-error-function to compilation-next-error
>> and just write:
>> 
>> (defun next-error (argp)
>> (interactive ...)
>> (with-current-buffer compilation-last-buffer
>> (funcall compilation-next-error-function argp))

> compilation-last-buffer is not necessarily what we want.  We need to
> find a suitable buffer, so you can run next-error anywhere and at any
> time.  That preserves the existing semantics of next-error; I don't
> think your version does.  I may be wrong, though.

My code was not intended to be taken as is, obviously.  I just wanted
to say is that instead of

    (defvar X-function nil)
    ...
    ..(if X-function (funcall X-function) (do-something))

you can do

    (defvar X-function 'X-default)
    (defun X-default () (do-something))
    ...
    ..(funcall X-function)


-- Stefan




reply via email to

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