[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46407: 27.1; Hooks with permanent-local-hook are not cleared of lamb
From: |
jakanakaevangeli |
Subject: |
bug#46407: 27.1; Hooks with permanent-local-hook are not cleared of lambdas |
Date: |
Tue, 25 May 2021 09:10:43 +0200 |
Lars Ingebrigtsen <larsi@gnus.org> writes:
> jakanakaevangeli <jakanakaevangeli@chiru.no> writes:
>
>> When kill-all-local-variables encounters a hook variable with its
>> 'permanent-local property set to 'permanent-local-hook, it removes from
>> its value every element except for t, functions with
>> 'permanent-local-hook property and anything that isn't a symbol
>> (see the comment at src/buffer.c:1072).
>>
>> This means that, for the following code
>>
>> (defvar 'some-hook nil)
>> (add-hook 'some-hook #'some-fun nil t)
>> (add-hook 'some-hook (lambda () (test)) nil t)
>>
>> whether some-fun is removed depends on some-fun's permanent-local-hook
>> property, which is expected. As for the anonymous lambda function, it is
>> not predictable, whether it will be kept or removed. In fact, it depends
>> on some-fun's permanent-local-hook property.
>
> Well, it depends on the hook's permanent-local-hook property, but it's
> true that add-hook will automatically set that for you if you pass in a
> symbol with that property set.
> So, yes, that's a strange side effect of this interface, but I'm not
> sure anything could be done about it at this stage (it was introduced in
> this form almost two decades ago).
On the other hand, this side effect is so undocumented and
undiscoverable (and most probably not really of any use as well), that I
highly doubt there is even a single instance of anyone relying in it
deliberately. I may be wrong though.
>
> jakanakaevangeli <jakanakaevangeli@chiru.no> writes:
>
>> Also one more thing:
>>
>> (defvar some-hook nil)
>> (add-hook 'some-hook #'some-fun nil t)
>> (put 'some-fun 'permanent-local-hook t)
>>
>> If we mark a function as permanent-local-hook only after adding it to a
>> hook, the hook symbol will not have its permanent-local property set to
>> 'permanent-local-hook, so some-fun will not be kept on removal of local
>> variables.
>>
>> This can be a real non-theoretical problem when adding an autoloaded
>> function to a hook.
>
> You mean if the property isn't part of the autoloaded signature? Yes,
> that's true.
Whoops, I forgot that one can simply put an autoload cookie on the
(put ...) form as well. Please ignore my second post.
> As far as I can tell, this permanent-local-hook stuff isn't used
> anywhere in the Emacs tree, and it seems like a pretty odd and (as this
> bug report shows) inconsistent interface. I'm not sure whether it's
> worth trying to fix, or we should just document that it's iffy.
I'm personally in favour of fixing the `kill-all-local-variables'
inconsistency (patch follows).
If not, then yes, we should document it in add-hook and fix the info
node I mentioned. Though that would leave virtually every local addition
of a lambda to a hook invalid and a possible bug (a quick grep reveals
that there are at least three such usages in Emacs itself).
diff --git a/src/buffer.c b/src/buffer.c
index 565577e75a..6933f89bd4 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1079,9 +1079,9 @@ reset_buffer_local_variables (struct buffer *b, bool
permanent_too)
/* Preserve element ELT if it's t,
if it is a function with a `permanent-local-hook'
property,
or if it's not a symbol. */
- if (! SYMBOLP (elt)
- || EQ (elt, Qt)
- || !NILP (Fget (elt, Qpermanent_local_hook)))
+ if (EQ (elt, Qt)
+ || (SYMBOLP (elt)
+ && !NILP (Fget (elt, Qpermanent_local_hook))))
newlist = Fcons (elt, newlist);
}
newlist = Fnreverse (newlist);
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
Best regards.