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

["Štěpán Němec" <stepnem@gmail.com>]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jul 15, 2011 at 10:52, Štěpán Němec <stepnem@gmail.com> wrote:
>
>> 1) If your reasoning about hooks being added via modes were correct, you
>> wouldn't have to remove even the global hook additions.
>
> Why? Global additions are not removed when the buffer's major mode is
> switched. Local variables, including local values of hooks, are.

Note I omitted the "major" part, i.e., it's not uncommon for minor modes
to make global hook additions. Sorry if that's not really related to the
problem at hand.

>> If it's faulty
>> (which is probably the case), both global and local hooks need to be
>> managed, as Kevin said.
>
> I'm more of the opinion that both should be un-managed. A look at the
> sources is enough to see that hook removal is currently ugly and
> ad-hoc, and ugly too.

Fine with me, as long as the documentation reflects this.

>> 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.
>
> Yes. The docstring for unload-feature has always promised more than it
> could reasonably accomplish. Yours is only one example.

Please do update it then.

[...]

> Both Kevin and you seem to think that unload-feature should do
> everything and that having to define FEATURE-unload-function is a bug
> or something like that. It is not.  I'm all for making unload-feature
> smarter, as long as it does not trample on the programmer's ability to
> do. I can perfectly well imagine unloading a package but setting a
> hook with an autoloading function from that same package.

Right... I do know about unload functions and use them where
appropriate. The important thing is that the documentation needs to
describe what actually happens, so whatever you decide to do about this,
please update the documentation (which, as you confirmed, needs to be
done anyway).

  Štěpán