From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup Date: Fri, 14 Oct 2022 12:53:14 +0200 Message-ID: <874jw6d6cl.fsf@gnus.org> References: <87bkrsr1g2.fsf@gnus.org> <875yi0qz5b.fsf@gnus.org> <83sfl4ihfo.fsf@gnu.org> <87mtbcp774.fsf@gnus.org> <877d2e5ba1.fsf@gnus.org> <87czc4v5id.fsf@gnus.org> <874jxfsv9o.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17016"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: germanp82@hotmail.com, 57627@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 14 12:54:38 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojIKr-0004D4-Ng for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 12:54:37 +0200 Original-Received: from localhost ([::1]:42524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojIKq-0002Sv-75 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 06:54:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojIKI-0002SB-HV for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 06:54:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36810) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojIKI-0003BK-9v for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 06:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojIKI-0004xi-5l for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 06:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Oct 2022 10:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57627-submit@debbugs.gnu.org id=B57627.166574480919025 (code B ref 57627); Fri, 14 Oct 2022 10:54:02 +0000 Original-Received: (at 57627) by debbugs.gnu.org; 14 Oct 2022 10:53:29 +0000 Original-Received: from localhost ([127.0.0.1]:35888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojIJl-0004wn-1Y for submit@debbugs.gnu.org; Fri, 14 Oct 2022 06:53:29 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:44956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojIJj-0004wM-Op for 57627@debbugs.gnu.org; Fri, 14 Oct 2022 06:53:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cKDxpuwLPmjvpIvicfMPckutLJ+/V9QMDdiTGpo5d30=; b=sDA77YdLbEA/x7NSX642WFl8sL s5U3UnvUi+5PfVjadfH+vuzhoGBlUsghmtlkaZy78opXRDbJj6SsZdG5pJTUvuV9hjl+tMMm4N5j0 vIsoEy+k5SFeb3DdgbXBKXozIZY2HZVYfJkm4GhNd/Vmcb4/xnf3yF8ekfLW7HZymMik=; Original-Received: from [84.212.220.105] (helo=downe) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojIJW-0005EL-Vr; Fri, 14 Oct 2022 12:53:17 +0200 In-Reply-To: <874jxfsv9o.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 10 Sep 2022 06:33:55 +0200") X-Now-Playing: Xeno & Oaklander's _Topiary_: "Worlding Worlds" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245396 Archived-At: Lars Ingebrigtsen writes: > Perhaps we should make the no-native-compile thing into code instead of > having it as a comment? I started futzing around with this again, but then wondered whether we should have a more general language mechanism for stuff like this. So I've added Stefan to the CCs; perhaps he's thought about this stuff before. So to recap the practical problem we have today and would like to fix: We put ;; no-native-compile: t into .el files to signal that we don't want them to be native-compiled. However, the machinery today doesn't see that when we want it to. That is, we load the .elc file, the nativecomp machinery then kicks in and adds the file to the async .eln list, which then forks off an Emacs which then loads the .el file and sees that cookie, and then does nothing. (And this will happen on every Emacs run.) So the machinery either has to inspect the .el file in addition to the .elc file (which is inefficient), or we need to put something into the .elc file to tell the machinery not to bother with generating the .eln. This is simple enough, of course -- we could just introduce a (no-native-compile) function that hooks into the machinery at the right point. But this reminds me of other "file-wide directives" that have been previously discussed over the years, and makes me wonder whether we should introduce something more general. As an example of an ad-hoc one that already exists, we have `defgroup' that makes all subsequent `defcustom' forms use that group in the same file. We've previously discussed (in i18n contexts) whether it should be possible to specify the translation domain of the file. And we have different Emacs Lisp dialects, and we have shorthands, which use comments to change the behaviour of the code, which is unsatisfactory. So... is it time to introduce something like `pragma'? That is, in this case, we'd say (pragma 'no-native-compile) somewhere in the file. We could have (pragma 'dynamic-binding) for future versions of Emacs when lexical binding is default but we want to allow people files to still be dynamic. And we could have (pragma 'shorthands "snu-" "some-nice-string-utils-") And, of course, for backwards/forwards compat, any unknown pragmas would be ignored.