bug#5026: 23.1; add-hook buffer local vs single func
Stefan Monnier
> Should run-hooks allow a single-function global value when it follows a
> `t' from a local value?
Actually, I think that run-hooks, add-hook and friends should throw at
least warnings when faced with this kind of obsolete "single
function" use.
Stefan
Stefan Monnier
Kevin Ryde
>
> Actually, I think that run-hooks, add-hook and friends should throw at
> least warnings when faced with this kind of obsolete "single
> function" use.
No need to actively take it away is there? Warnings could only blast
users who had old but otherwise perfectly good setq's in their .emacs,
couldn't it?
Stefan Monnier
>> least warnings when faced with this kind of obsolete "single
>> function" use.
> No need to actively take it away is there?
It would be good to get rid of it, yes. It has various misfeatures.
Stefan
Richard Stallman
visibly when the old usage occurs. Then we will see if there are
really any widely used packages which have the problem. Maybe we will
see that it is painless to eliminate that usage now.
Kevin Ryde
>
> It has various misfeatures.
Such as? Surely a single function is unambiguous, and needs only a
little care from run-hooks and friends to remain compatible.
(A little care of course always being better than sending thousands of
people for a ride on the rolling-incompatibility treadmill!)
Kevin Ryde
>
> It would be interesting for some users to install code to warn very
> visibly when the old usage occurs. Then we will see if there are
> really any widely used packages which have the problem.
One in particular I think is fill-nobreak-predicate. It was a single
function in Emacs 21, later became a hook. Anyone who followed the
advice of the time to set it to a predicate has had it working fine with
the hook, but taking away the single-function feature of hooks would I
believe break that. :-(
Stefan Monnier
> people for a ride on the rolling-incompatibility treadmill!)
For the long term maintainability of the code, adding more quirks into
the code for the sake of a few users who can fix their problems easily
is not such a hot idea either.
The key here is "fix ... easily", which can be done by adding code that
detects the problem and warns the user about it.
Stefan
Stefan Monnier
Stefan Monnier
Emacs bug Tracking System
with message-id <87ljghg...@stupidchicken.com>
and subject line Re: bug#5026: 23.1; add-hook buffer local vs single func
has caused the Emacs bug report #5026,
regarding 23.1; add-hook buffer local vs single func
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gn...@gnu.org
immediately.)
--
5026: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5026
Emacs Bug Tracking System
Contact bug-gn...@gnu.org with problems
Kevin Ryde
>
> Still, as long as we're still supporting the obsolete format, it's easy
> enough to fix run-hooks to recognize it; I've checked in such a fix.
Good stuff.
As an idea, maybe the bit of add-hook that upgrades a single func to a
list could be split out and forcibly applied in places that care, like
customize or whatever. I wouldn't mind if even run-hooks upgraded the
value. This could preserve compatibility for now, and be a half step
towards breaking compatibility later.