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: Wed, 28 Feb 2018 18:22:22 -0500 Message-ID: References: <827ed6de-fd90-144e-53dd-50163a937b63@gmail.com> <4e07d7b4-f1f7-0d5d-5f2a-b5e491ab4303@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1519860077 31427 195.159.176.226 (28 Feb 2018 23:21:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 23:21:17 +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 Thu Mar 01 00:21:13 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 1erB28-0007j5-Pp for ged-emacs-devel@m.gmane.org; Thu, 01 Mar 2018 00:21:12 +0100 Original-Received: from localhost ([::1]:47569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erB4B-00055m-6l for ged-emacs-devel@m.gmane.org; Wed, 28 Feb 2018 18:23:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erB3T-00055J-DS for emacs-devel@gnu.org; Wed, 28 Feb 2018 18:22:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erB3O-0007Nr-80 for emacs-devel@gnu.org; Wed, 28 Feb 2018 18:22:35 -0500 Original-Received: from [195.159.176.226] (port=56997 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erB3N-0007Mp-VO for emacs-devel@gnu.org; Wed, 28 Feb 2018 18:22:30 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1erB1J-00037k-3B for emacs-devel@gnu.org; Thu, 01 Mar 2018 00:20:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:xTPPyqgPrQIX2pv9bexELghzO64= 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:223184 Archived-At: > 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