emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 13 Apr 2018 14:02:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> Flycheck defines a few of macros.  Our users want to write code that depends
> on them in their init files, but don't care for that code to run unless they
> are in fact using Flycheck.

I don't think users really want to use your macros.
Instead they have to use your macros in order to get something else done.

E.g. you could make it unnecessary for them to use eval-after-load by
letting them write something like

    (setq flycheck-extra-commands
          '((foo1 "blibla" :command bar :error-patterns baz)
            (foo2 "blabli" :command tar :error-patterns taz)))

instead of some uses of flycheck-define-command.

That same kind of approach is used for font-lock, outline, imenu, etc..

It's not always ideal: e.g. for syntax-propertize I did not follow this
approach and did decide to rely on a `syntax-propertize-rules` macro
because I felt there was a substantial gain to processing these rules in
a macro.  I think font-lock would also benefit from a similar macro.

But in the case of flycheck-define-command at least, I don't see much
benefit to having it be a macro instead of some inert data in
a variable.

> Couldn't we just define a with-macroexpand-and-eval-after-load macro,
> and call it a day?

I'd be perfectly happy to add a new macro like

    (defmacro with-lazy-macro-expansion (&rest body)
      `(eval '(progn ,@body) lexical-binding))

but I'm reluctant to add a macro that's specific to eval-after-load
since the problem is more general.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]