Re: emacs-26: `with-eval-after-load' docstring omission

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Is that because macroexpansion happens eagerly in the body of the defun, too?

More or less.  It's because it *can* happen eagerly (it also does
nowadays in many cases, but the exact time when macroexpansion takes
place is not specified precisely and it can&does vary depending on
circumstances and Emacs version).

> I guess I just don't expect that to happen unless the file is
> byte-compiled, really :/

Whether the code is byte-compiled or not is an implementation detail
which could change.  Any code which depends on whether it gets compiled
is considered as buggy in my book.

>> In your case, you do want the quote because you need to delay
>> macro-expansion, but I think it's cleaner to solve this problem by
>> *explicitly* using a quote, rather than by relying on the messy
>> semantics of the macro/function you happen to be using.
> I'm not sure I follow: doesn't the compiler macro mean that even explicitly
> using a quote isn't enough?

In that one specific case, yes, but in general using a quote is sufficient.

You should not use `eval-after-load` nowadays, you should only use
`with-eval-after-load`, so you'd write something like

    (with-eval-after-load 'flycheck
      ;; Use eval+quote to delay macro expansion.
      (eval '(flycheck-define-command ...)))

>> E.g. your exact same problem could show up if you used, say,
>>     (add-hook 'flycheck-mode-hook ...)
>> instead of
>>     (with-eval-after-load ...)
>> but you wouldn't ask for a change in add-hook to "solve" your problem.
>
> Would the problem there be that the body of the lambda I'd pass to add-hook
> would be eagerly macro-expanded?

At least could, yes.

> I think the big difference between these two is that I expect
> `with-eval-after-load` to really behave differently, and the reason for
> expecting that is that we don't otherwise have a convenient way to delay
> macroexpansion and execution of a form until a file is loaded, right?
> Maybe we need a `with-macroexp-and-eval-after-load`?

What I'm trying to say is that delaying macroexpansion is something
that's needed in many more cases than in conjunction to
`eval-after-load` so any solution specifically linked to
`eval-after-load` is just an ad-hoc hack.


        Stefan