GNU bug report logs - #56210
29.0.50; Keyboard macros do not trigger after-change-functions

Previous Next

Full log

Message #38 received at 56210 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: 56210 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#56210: 29.0.50; Keyboard macros do not trigger
 after-change-functions
Date: Mon, 27 Jun 2022 20:17:32 +0300

> Date: Mon, 27 Jun 2022 13:07:44 -0400
> Cc: larsi <at> gnus.org, 56210 <at> debbugs.gnu.org
> From: Richard Hansen <rhansen <at> rhansen.org>
> 
> > Your test calls with-current-buffer-window, which calls
> > temp-buffer-window-setup, which inhibits modification hooks:
> 
> Yup, that's it!  If I set `inhibit-modification-hooks' back to nil then it works.  Thank you.
> 
> I thought I had a `(should (null inhibit-modification-hooks))` at some point in the past to rule that out, but I must not have had that inside the `with-current-buffer-window'.
> 
> Perhaps the documentation should be updated to indicate that the modification hooks are inhibited?  I can cook up a patch.

Is it really a good idea?  In general, all the 'with-SOMETHING' macros
are likely to inhibit modification hooks, since they erase the
temporary buffers high and low.  We'd need to stick these factoids in
umpteen APIs, and we'll still forget some.  E.g., in this case, even
if temp-buffer-window-setup was documented to inhibit modification
hooks. how would you know it is relevant to your case -- it is not
explicitly called anywhere.

I think the rule of thumb should be to assume that any temporary
buffer has these kinds of hooks disabled, and if one needs them
enabled, one should enable them explicitly.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.