question about "Making change-major-mode-hook buffer-local while locally let-bound!"

question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Drew Adams]

I use a modified definition of `pp-display-expression' that binds these two
hooks to nil around the call (emacs-lisp-mode), to prevent the hooks from
running:

(let ((emacs-lisp-mode-hook    nil)
      (change-major-mode-hook  nil))
  (emacs-lisp-mode))

That is the only change - otherwise, emacs -Q.

(No, I do not remember just why I added the c-m-m-h binding (years ago), but I
probably did so because of some problem or annoyance the hook sometimes caused.)

The c-m-m-h binding now results in this message being displayed:

"Making change-major-mode-hook buffer-local while locally let-bound!"

Question:
What is the right way to prevent these hooks from running here?

Do I need to use remove-hook followed by add-hook: saving, emptying and
repopulating the hook? What's the right approach?

---

Also, out of curiosity, where is `change-major-mode-hook' being made
buffer-local?  Grepping the lisp sources shows only these hits that seem to
involve making it local:

gnus/gnus-msg.el:449: (gnus-make-local-hook 'change-major-mode-hook)
arc-mode.el:771: (set (make-local-variable 'change-major-mode-hook)
'archive-desummarize)

But arc* and gnus* are not present in `features'.  A wild guess suggests maybe
something in font-lock is the culprit (emacs -Q shows `(font-lock-change-mode
t)' as the local value), but I haven't found anything.  I didn't find anything
by skimming the C code either.

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-06-14 on 3249CTO

RE: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[MON KEY]

> Also, out of curiosity, where is `change-major-mode-hook' being made
> buffer-local?  Grepping the lisp sources shows only these hits that
> seem to involve making it local:

Maybe something to do with the `lisp-mode-variables' form in the
derived-mode definition of `emacs-lisp-mode' in
emacs-lisp/lisp-mode.el ??

,---- (documentation 'lisp-mode-variables))
|
| {...}
|
| The LISP-SYNTAX argument is used by code in inf-lisp.el and is
| (uselessly) passed from pp.el, chistory.el, gnus-kill.el and
| score-mode.el.
|
`----

--
/s_P\

Re: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Johan Bockgård]

"Drew Adams" <drew.adams@oracle.com> writes:

> But arc* and gnus* are not present in `features'. A wild guess
> suggests maybe something in font-lock is the culprit (emacs -Q shows
> `(font-lock-change-mode t)' as the local value), but I haven't found
> anything.

(add-hook HOOK ... LOCAL)

Re: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Stefan Monnier]

> (let ((emacs-lisp-mode-hook    nil)
>       (change-major-mode-hook  nil))
>   (emacs-lisp-mode))
[...]
> What is the right way to prevent these hooks from running here?

E.g.:

 (make-local-variable 'emacs-lisp-mode-hook)
 (make-local-variable 'change-major-mode-hook)
 (let ((emacs-lisp-mode-hook    nil)
       (change-major-mode-hook  nil))
   (emacs-lisp-mode))

> Do I need to use remove-hook followed by add-hook: saving, emptying and
> repopulating the hook? What's the right approach?

Those hooks are not permanent-local, so they'll be emptied and
repopulated as needed by the call to emacs-lisp-mode.
So you could probably just do:

 (set (make-local-variable 'emacs-lisp-mode-hook) nil)
 (set (make-local-variable 'change-major-mode-hook) nil)
 (emacs-lisp-mode)

Or use `remove-hook' to eliminate only the particular values which are
undesired rather than removing them all.

> Why bother?  What is gained by having such a runtime message?

This messages is linked to a problematic circumstance where Emacs tries
to do its best, but where the code should ideally be changed to avoid
such a circumstance.  So it's important to detect and warn about those
cases, and sadly, I don't know how to do it at a better time.


        Stefan

RE: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Drew Adams]

>  (make-local-variable 'emacs-lisp-mode-hook)
>  (make-local-variable 'change-major-mode-hook)
>  (let ((emacs-lisp-mode-hook    nil)
>        (change-major-mode-hook  nil))
>    (emacs-lisp-mode))
> 
> Those hooks are not permanent-local, so they'll be emptied and
> repopulated as needed by the call to emacs-lisp-mode.
> So you could probably just do:
> 
>  (set (make-local-variable 'emacs-lisp-mode-hook) nil)
>  (set (make-local-variable 'change-major-mode-hook) nil)
>  (emacs-lisp-mode)

Very clear; thank you.

> > What is gained by having such a runtime message?
> 
> This messages is linked to a problematic circumstance where 
> Emacs tries to do its best, but where the code should ideally
> be changed to avoid such a circumstance.  So it's important
> to detect and warn about those cases, and sadly, I don't know
> how to do it at a better time.

This, however, is not so clear. ;-)  What I take away from it is that there is
some unspecified problem somewhere that has no easy solution, so to encourage
programmers not to write code that might manifest the problem you think it best
to issue a runtime message about the problematic code.

That doesn't sound like a good approach, to me, but you know the details, not I.
I suppose it is a serious problem, in order to make it warrant such a strange
remedy.

Anyway, thanks very much for the explanation above.

RE: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Davis Herring]

> This, however, is not so clear. ;-) What I take away from it is that
> there is some unspecified problem somewhere that has no easy solution,
> so to encourage programmers not to write code that might manifest the
> problem you think it best to issue a runtime message about the
> problematic code.

There is no "unspecified problem": it does weird (and possibly buggy --
I'm not sure on this point) things to make buffer-local values for
variables that are let-bound at the time.  (I know it does buggy things if
you call `set-buffer' while a variable is both let-bound and buffer-local;
this is similar.)

What "has no easy solution" is that code that causes this undesirable
condition is hard to detect statically, so we detect it dynamically
instead.  But we believe that all such code can be fixed, so:

> That doesn't sound like a good approach, to me, but you know the
> details, not I.  I suppose it is a serious problem, in order to make
> it warrant such a strange remedy.

The remedy is not so strange if it persists only until the code that
triggers it is removed.  Since there is an easy way for your code to avoid
it, that's one less case now where it will be generated.

In other words this message is akin to an assertion failure message that
asks the user to file a bug report.  That's why it's OK that it's not the
user's doing.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: question about "Making change-major-mode-hook buffer-local while locally let-bound!"

[Drew Adams]

> In other words this message is akin to an assertion failure 
> message that asks the user to file a bug report.

If that is the purpose of this message to the user, then the message should say
that or something similar.

The language of the current message is, IMO, not targeted to users and is not
very likely to have the intended report-a-bug effect.