[Top][All Lists]

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

bug#14926: 24.3.50; Warning "`make-variable-buffer-local' should be call

From: Drew Adams
Subject: bug#14926: 24.3.50; Warning "`make-variable-buffer-local' should be called at toplevel"
Date: Fri, 16 Aug 2013 10:58:42 -0700 (PDT)

> > The message still suggests that using make-variable-buffer-local
> > other than at toplevel is erroneous.
> Notice that the message is only emitted when the argument to the"
> function is a constant.  I know of only one case where it is "not
> erroneous" to have such a call not at top-level (from message.el):
>    ;; FIXME: On XEmacs this causes problems since let-binding like:
>    ;; (let ((message-options message-options)) ...)
>    ;; as in `message-send' and `mml-preview' loses to buffer-local
>    ;; variable initialization.
>    (unless (featurep 'xemacs)
>      (make-variable-buffer-local 'message-options))
> So yes, I think in 99% of the cases, it's erroneous.

Hm.  A certain Stefan said this previously: ;-)

 >> > 2. What is wrong with code such as this at top level?
 >> Nothing.  But most of the cases I bumped into... were cases
 >> where the author had confused make-local-variable and
 >> make-variable-buffer-local.

Putting the two statements together, I guess you're saying:

1. There is nothing *inherently* wrong with
`make-variable-buffer-local' at other than top level, at least in
cases like the example cited in the bug report:

(when (fboundp 'foo)
  (defvar toto 42 "...")
  (make-variable-buffer-local 'toto))

2. But though there is nothing inherently wrong with that, in 99%
of the cases it is erroneous to use `make-variable-buffer-local',
except at top level.

That would indeed be a good case for a warning.  (And perhaps a
note in the doc.)  But see my previous mail about the content of
the warning message: it should point to `make-local-variable' and
it should not mention "top level" at all.

reply via email to

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