all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Andrea Corallo <akrl@sdf.org>
Cc: germanp82@hotmail.com, 57627@debbugs.gnu.org,
	Eli Zaretskii <eliz@gnu.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup
Date: Fri, 14 Oct 2022 12:53:14 +0200	[thread overview]
Message-ID: <874jw6d6cl.fsf@gnus.org> (raw)
In-Reply-To: <874jxfsv9o.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 10 Sep 2022 06:33:55 +0200")

Lars Ingebrigtsen <larsi@gnus.org> 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.






  parent reply	other threads:[~2022-10-14 10:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 11:38 bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup German Pacenza
2022-09-06 15:02 ` Lars Ingebrigtsen
2022-09-06 15:46   ` German Pacenza
2022-09-06 15:51     ` Lars Ingebrigtsen
2022-09-06 16:33       ` Andrea Corallo
2022-09-06 16:41         ` Eli Zaretskii
2022-09-06 19:23           ` Andrea Corallo
2022-09-06 20:40             ` Lars Ingebrigtsen
2022-09-07  2:33               ` Eli Zaretskii
2022-09-07 12:47                 ` Lars Ingebrigtsen
2022-09-07 13:01                   ` German Pacenza
2022-09-07 13:06                     ` Lars Ingebrigtsen
2022-09-07 13:41                       ` Lars Ingebrigtsen
2022-09-07 13:08                   ` Eli Zaretskii
2022-09-07 13:10                     ` Lars Ingebrigtsen
2022-09-07 18:06               ` Andrea Corallo
2022-09-08 11:57                 ` Lars Ingebrigtsen
2022-09-09 12:57                   ` Andrea Corallo
2022-09-09 17:09                     ` Lars Ingebrigtsen
2022-09-09 19:03                       ` Andrea Corallo
2022-09-10  4:33                         ` Lars Ingebrigtsen
2022-09-10  4:38                           ` Lars Ingebrigtsen
2022-10-14 10:53                           ` Lars Ingebrigtsen [this message]
2022-10-14 19:00                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-15 10:13                               ` Lars Ingebrigtsen
2022-10-15 14:19                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-16  8:21                                   ` Lars Ingebrigtsen
2022-10-17  7:47                                     ` Andrea Corallo
2022-10-17  8:49                                       ` Lars Ingebrigtsen
2022-10-17  8:52                                         ` Andrea Corallo
2022-10-17  9:06                                         ` Eli Zaretskii
2022-10-17  9:13                                           ` Lars Ingebrigtsen
2022-10-17 11:59                                     ` Arash Esbati
2022-10-17 12:01                                       ` Lars Ingebrigtsen
2022-10-17 12:09                                         ` Arash Esbati
2022-10-17 12:21                                           ` Lars Ingebrigtsen
2022-10-17 12:31                                             ` Lars Ingebrigtsen
2022-10-17 12:53                                               ` Arash Esbati
2022-10-17 12:59                                               ` German Pacenza
2024-08-28  2:04 ` Phil Sainty
2024-09-06  8:44   ` Andrea Corallo
2024-09-14  7:50     ` Eli Zaretskii
2024-09-14 12:13       ` Phil Sainty
2024-09-28  8:53         ` Eli Zaretskii
2024-10-12 11:21           ` Eli Zaretskii
2024-10-13 21:20             ` Andrea Corallo
2024-10-13 22:12               ` Andrea Corallo
2024-10-15 13:01                 ` Phil Sainty
2024-10-15 19:20                   ` Andrea Corallo
2024-10-15 19:56                     ` Phil Sainty
2024-10-15 20:27                       ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jw6d6cl.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=57627@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=eliz@gnu.org \
    --cc=germanp82@hotmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.