bug#59559: 28.1; `minibuffer-with-setup-hook' with :append

[Drew Adams]

> > While the syntax of this macro is a bit unusual, with the background of
> > the terminology used in the rest of Emacs the description allows only
> > one interpretation: when we say that the argument (of a macro) is of a
> > certain form, the unevaluated s-exp is meant.

But that's _not_ what's meant here.  The doc string:

  By default, FUN is prepended to 'minibuffer-setup-hook'.
  But if FUN is of the form '(:append FUN1)', FUN1 will
  be appended to 'minibuffer-setup-hook' instead of prepending it.

Whether FUN is or is not of that :append form, per
your presumption - "the terminology used in the rest
of Emacs", the UNevaluated sexp is meant.  But that's
not the case here.

Try it:

(defun toto () (message "@@@@@@@@@@@@@@"))
(minibuffer-with-setup-hook toto (message "************"))

Debugger entered--Lisp error: (void-variable toto)
  (let ((fun toto)
    (setup-hook (make-symbol "minibuffer-setup")))
    (fset setup-hook
          #'(lambda nil
              (remove-hook 'minibuffer-setup-hook setup-hook)
              (funcall fun)))
    (unwind-protect (progn (add-hook 'minibuffer-setup-hook setup-hook)
                           (message "************"))
      (remove-hook 'minibuffer-setup-hook setup-hook)))

Not to mention that the unevaluated form (:append toto)
also exhibits the same problem - it too doesn't fit
"the terminology used in the rest of Emacs".

It is just not the case that "the unevaluated s-exp is
meant" for macro `minibuffer-with-setup-hook'.  The
_evaluated_ sexp is meant for FUN as the arg, and the
_evaluated_ FUN1 _part_ of the sexp (:append FUN1) is
meant for that form of the arg.

That's what this bug report is about.  And yes, this
_is_ quite unusual.  IMO it's not the best interface
design, but there's nothing really "wrong" with
defining a macro whose argument handling is this
complicated.

There is something wrong, however, with not making
this unusual behavior clear in the macro's doc, IMHO.

> Full agreement, my thoughts exactly.
> 
> > Else we explicitly say that the value or 
> > evaluation result should have certain properties.
> 
> That would require us to write a much more complex doc string in this
> case, and then do the same for all the other macros we have.  So I
> don't think this is a good idea.

The "much more complex doc string", which is not much
more complex IMO, is needed because the behavior of
the macro itself is complex - it is _not_ the simple
behavior you've both said it is.

It's not the usual case for a macro (that the args
aren't evaluated).  And it's not the also usual case
that some of the args are evaluated but others are not.

It's the unusual case that one of the args is eval'd
if it has one form, and only _part_ of that arg is
eval'd and used if it has another form.

I say all this because it seems like you two are still
discussing this.  But if Eli has reached a decision
that there's no bug (have you, Eli?) then end of story.