[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-26: `with-eval-after-load' docstring omission
From: |
Stefan Monnier |
Subject: |
Re: emacs-26: `with-eval-after-load' docstring omission |
Date: |
Wed, 28 Feb 2018 18:22:22 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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
Re: emacs-26: `with-eval-after-load' docstring omission, Stefan Monnier, 2018/02/27