From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs-26: `with-eval-after-load' docstring omission Date: Fri, 13 Apr 2018 14:02:50 -0400 Message-ID: References: <827ed6de-fd90-144e-53dd-50163a937b63@gmail.com> <4e07d7b4-f1f7-0d5d-5f2a-b5e491ab4303@gmail.com> <35b3a8a6-6cf1-bb0b-c0b6-e8e25fa803fc@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523642525 9857 195.159.176.226 (13 Apr 2018 18:02:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Apr 2018 18:02:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 13 20:02:01 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f731M-0002P3-7D for ged-emacs-devel@m.gmane.org; Fri, 13 Apr 2018 20:02:00 +0200 Original-Received: from localhost ([::1]:42855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f733S-0000FQ-T7 for ged-emacs-devel@m.gmane.org; Fri, 13 Apr 2018 14:04:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f732O-0000F3-0v for emacs-devel@gnu.org; Fri, 13 Apr 2018 14:03:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f732K-0000cH-43 for emacs-devel@gnu.org; Fri, 13 Apr 2018 14:03:04 -0400 Original-Received: from [195.159.176.226] (port=47367 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f732J-0000br-TH for emacs-devel@gnu.org; Fri, 13 Apr 2018 14:03:00 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1f730A-0000rB-Ng for emacs-devel@gnu.org; Fri, 13 Apr 2018 20:00:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:5K33wFeOM46EcjRYGb1HJCfeams= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224553 Archived-At: > 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