[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-26: `with-eval-after-load' docstring omission
From: |
Clément Pit-Claudel |
Subject: |
Re: emacs-26: `with-eval-after-load' docstring omission |
Date: |
Sat, 17 Mar 2018 02:01:33 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
On 2018-02-28 18:22, Stefan Monnier wrote:
> 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 ...)))
I got bitten by this again today, this time with this:
(with-eval-after-load 'flycheck
(push "npx" (flycheck-checker-get 'javascript-eslint 'command)))
… which failed with this message when Flycheck was actually loaded:
Debugger entered--Lisp error: (void-function \(setf\ flycheck-checker-get\))
(\(setf\ flycheck-checker-get\) (cons "npx" (flycheck-checker-get
'javascript-eslint 'command)) 'javascript-eslint 'command)
I'm slowly developing the habit of writing (with-eval-after-load 'flycheck
(eval '(…))), but I'm really not a fan of this pattern :/
What do we gain from byte-compiling the bodies of with-eval-after-load forms?
Byte-compilation warnings for undefined variables, but these are usually false
positives (precisely because the variables in a with-eval-after-load are often
defined by the package in question). And some performance, but
with-eval-after-load is discouraged in packages and its body typically runs
once (or very few times?), so its performance should be essentially irrelevant.
Maybe we can find a way to prevent macro-expansion issues and make the behavior
more intuitive?
Cheers,
Clément.
- Re: emacs-26: `with-eval-after-load' docstring omission,
Clément Pit-Claudel <=