Re: Idempotency of add-hook wrt lambda expressions

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Reitter writes:

 > On 4 Mar 2009, at 09:18, Stefan Monnier wrote:
 > 
 > > As a general rule, you should not put a lambda but a function name
 > > (i.e. a symbol) instead, to avoid all those problems (and be able to
 > > replace the function with a newer version of it).  But occasionally
 > > a lambda is really exactly what you want, of course.

 > People haven't adopted this, and this is pretty annoying.
 > 
 > A similar case are commands bound to menu items (or any other keys): C- 
 > h k does not bring up something useful for keys that are just bound to  
 > a lambda term.
 > 
 > As for hooks, is a lambda expression ever suitable to be added to a  
 > hook?
 > Would it make sense to change add-hook such that only true function  
 > names are allowed?

In all these cases the problem that you consistently run into is that
Emacs Lisp doesn't have namespaces/packages.  It's very common to want
to make a small tweak to a command's default arguments when it's used
as a hook or menu item, and adding more symbols for that just feels
wrong.  Not to mention getting in the way of completion.

lambdas may have docstrings, and probably things like C-h k would find
them if provided.  Hm, easy enough to check:

  (define-key global-map [(control c) z]
              (lambda () "Found doc!" (interactive) (message "yowza")))

C-h k C-c z ==>
C-c z runs (lambda nil Found doc! (interactive) (message yowza))

Found doc!

So the obvious workaround is to report a bug if a lambda in a menu
item doesn't have a docstring.  Maybe there should be a describe-hook
help function that returns a buffer like

----------------------------------------------------------------
foo-hook runs, in this order:

1. default-foo-hook-function
Drink foo in bar.

2. (lambda ...)
Call auxiliary-foo-hook-function with argument "hair of dog".
----------------------------------------------------------------