Subject: Re: bug#5293: 23.1; unload-feature on buffer-local hooks

From: Štěpán Němec <[email-masked]>
Date: Fri, 15 Jul 2011 10:52:30 +0200

Juanma Barranquero <[email-masked]> writes:

> On Fri, Jul 15, 2011 at 02:26, Kevin Ryde <[email-masked]> wrote:
>
>> Or conversely, it's undesirable to leave behind an unbound func in a
>> hook, and the same undesirability as to a buffer-local value as a global
>> value.
>
> But the usual case is that these buffer-local values are set via major
> modes also defined in the same package, and so they are automatically
> removed when the major modes are disabled (i.e., when the buffers are
> switched to other major modes). The only case where a buffer-local
> value is left behind is when the package's code sets it in
> non-standard ways, and in this case, it's the package responsability
> to define a FEATURE-unload-function to undo the changes.
>
> The philosophy behind unload-feature is: we try to automatically undo
> the easy/standard things, and give the package the opportunity to undo
> the hard/unstandard things itself. And I think it's the right
> approach.

1) If your reasoning about hooks being added via modes were correct, you
wouldn't have to remove even the global hook additions. If it's faulty
(which is probably the case), both global and local hooks need to be
managed, as Kevin said.

2) The `unload-feature' docstring says it undoes "any additions that the
library has made to hook variables", but that's apparently not what's
really happening, so if things stay as they are, the doc string should
be corrected.

3) Are local hook additions really such a "hard/unstandard" thing to
undo?

  Štěpán