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 whilelocally let-bound!"

[Drew Adams]

Also, should this message really be displayed at runtime?  It seems like the
kind of commentary-on-source-code that would be more appropriate for the
byte-compiler.  Why subject runtime users to such commentary?  In the code in
question, this message is shown each time a pp command is used.

And what's the best way to simply silence this message?  (Yes, I know I can flet
`message' etc., but is that the best approach here?)

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

[Davis Herring]

> Also, should this message really be displayed at runtime?  It seems
> like the kind of commentary-on-source-code that would be more
> appropriate for the byte-compiler.  Why subject runtime users to such
> commentary?  In the code in question, this message is shown each time
> a pp command is used.

The byte-compiler doesn't know that a variable is let-bound at the time
that you are making it buffer-local.  I don't suppose it's theoretically
impossible (cf. Rice's theorem) for the byte-compiler to detect
(potential) calls to functions that make certain variables local (since so
few functions do so) within let-bindings for those same variable, but it
would be a lot of effort.

That said, we could arrange for the message to be shown only once per
variable per session.  It wouldn't be perfect, since more than one piece
of code might do this for the same variable, but hopefully there are so
few instances of this that there would be no collisions.

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 whilelocally let-bound!"

[Drew Adams]

> > Also, should this message really be displayed at runtime?  It seems
> > like the kind of commentary-on-source-code that would be more
> > appropriate for the byte-compiler.  Why subject runtime users to
> > such commentary?  In the code in question, this message is shown 
> > each time a pp command is used.
> 
> The byte-compiler doesn't know that a variable is let-bound 
> at the time that you are making it buffer-local.

I was not suggesting that the byte-compiler should try to do this either. ;-)
My point was that this is a commentary on code, not help for the user.  It is
the _kind_ of thing (comment on code) that the byte-compiler does.  It is not
the kind of thing that we normally put in runtime messages to the user.

My question was why we would even think about subjecting Emacs _users_ to such a
code-commenting message.

> That said, we could arrange for the message to be shown only once per
> variable per session.  It wouldn't be perfect, since more than one
> piece of code might do this for the same variable, but hopefully 
> there are so few instances of this that there would be no collisions.

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

This kind of suggestion/hint belongs in the docs perhaps, but why also interrupt
users with it?  I have a hard time believing we would do this by design (not to
mention using `!' in such a message).

Messages to the user should generally reflect things the _user_ has done or is
able to do.  Telling a user that some executing code is "making
change-major-mode-hook buffer-local while [it is] locally let-bound [by some
other code]" is ridiculous, er, misguided, IMHO.

Anyway, this was only a side question.  Assuming this _will_ be imposed on us
(on n'arrete pas le progres), what is the answer to my original query?  What is
a good way to inhibit `change-major-mode-hook' temporarily?  And what is a good
way to suppress this message (preferably only this message)?

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-localwhile locally let-bound!"

[Drew Adams]

> > Also, out of curiosity, where is `change-major-mode-hook'
> > being made buffer-local?
> 
> (add-hook HOOK ... LOCAL)

Ah yes, of course; thanks.  So it seems that there are 8 zillion places where
this is done.

But what about my real question?  What is a good way to inhibit
`change-major-mode-hook' temporarily?  And what is a good way to suppress this
message (and preferably only this message)?

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.

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\