bug#5026: 23.1; add-hook buffer local vs single func

bug#5026: 23.1; add-hook buffer local vs single func

[Kevin Ryde]

Evaluating

    (progn
      (defvar foo nil)

      (defun func1 ()
        (error "this is func 1"))
      (defun func2 ()
        (message "this if func 2"))


      (setq foo 'func1)
      (add-hook 'foo 'func2
                nil ;; prepend
                t)  ;; buffer-local

      (run-hooks 'foo))

returns nil, where I expected the run-hooks to run both func2 and func1,
raising the error in func1.

The elisp manual under "Setting Hooks" says

    `add-hook' can handle the cases where ... its value is
    a single function;

but that doesn't seem to be so when extending a single function to a
buffer-local value.

I suspect it's run-hooks which should be blamed rather than add-hook.
Should run-hooks allow a single-function global value when it follows a
`t' from a local value?

I expect this arises only rarely.  But if it does then it's a pretty
subtle way to miss out on a function you thought you had in a hook.




In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-09-14 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

bug#5026: 23.1; add-hook buffer local vs single func

[Stefan Monnier]

> I suspect it's run-hooks which should be blamed rather than add-hook.
> 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

bug#5026: 23.1; add-hook buffer local vs single func

[Kevin Ryde]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> 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?

bug#5026: 23.1; add-hook buffer local vs single func

[Stefan Monnier]

>> 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?

It would be good to get rid of it, yes.  It has various misfeatures.


        Stefan

bug#5026: 23.1; add-hook buffer local vs single func

[Richard Stallman]

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.  Maybe we will
see that it is painless to eliminate that usage now.

bug#5026: 23.1; add-hook buffer local vs single func

[Kevin Ryde]

Richard Stallman <rms@gnu.org> writes:
>
> 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. :-(

bug#5026: 23.1; add-hook buffer local vs single func

[Kevin Ryde]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> 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!)

bug#5026: 23.1; add-hook buffer local vs single func

[Stefan Monnier]

> (A little care of course always being better than sending thousands of
> 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

bug#5026: marked as done (23.1; add-hook buffer local vs single func)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

Your message dated Fri, 01 Jan 2010 12:16:30 -0500
with message-id <87ljghg2z5.fsf@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-gnu-emacs@gnu.org
immediately.)


-- 
5026: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5026
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 4394 bytes --]

From: Kevin Ryde <user42@zip.com.au>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; add-hook buffer local vs single func
Date: Tue, 24 Nov 2009 08:04:41 +1100
Message-ID: <87bpitlzpy.fsf@blah.blah>

Evaluating

    (progn
      (defvar foo nil)

      (defun func1 ()
        (error "this is func 1"))
      (defun func2 ()
        (message "this if func 2"))


      (setq foo 'func1)
      (add-hook 'foo 'func2
                nil ;; prepend
                t)  ;; buffer-local

      (run-hooks 'foo))

returns nil, where I expected the run-hooks to run both func2 and func1,
raising the error in func1.

The elisp manual under "Setting Hooks" says

    `add-hook' can handle the cases where ... its value is
    a single function;

but that doesn't seem to be so when extending a single function to a
buffer-local value.

I suspect it's run-hooks which should be blamed rather than add-hook.
Should run-hooks allow a single-function global value when it follows a
`t' from a local value?

I expect this arises only rarely.  But if it does then it's a pretty
subtle way to miss out on a function you thought you had in a hook.




In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-09-14 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t



[-- Attachment #3: Type: message/rfc822, Size: 2649 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, Kevin Ryde <user42@zip.com.au>
Cc: 5026-done@emacsbugs.donarmstrong.com
Subject: Re: bug#5026: 23.1; add-hook buffer local vs single func
Date: Fri, 01 Jan 2010 12:16:30 -0500
Message-ID: <87ljghg2z5.fsf@stupidchicken.com>

> > I suspect it's run-hooks which should be blamed rather than add-hook.
> > 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.

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.

bug#5026: 23.1; add-hook buffer local vs single func

[Kevin Ryde]

Chong Yidong <cyd@stupidchicken.com> writes:
>
> 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.