GNU bug report logs -
#77469
finder-inf is not autocompiled on installation
Previous Next
Full log
Message #17 received at 77469 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 4 Apr 2025, 12:57 Eli Zaretskii, <eliz <at> gnu.org> wrote:
> > From: Gergely Riskó <gergely.risko <at> gmail.com>
> > Date: Fri, 4 Apr 2025 05:17:44 +0200
> > Cc: 77469 <at> debbugs.gnu.org
> >
> > On Thu, Apr 3, 2025 at 6:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Why is it important to compile it? It defines 2 variables, and has no
> > > code. What would be gained by compiling it?
> >
> > Hey Eli, thanks for coming back to me this fast.
> >
> > The background is this:
> > https://github.com/radian-software/straight.el/issues/1190
> >
> > I'm trying to optimize my .emacs, and as part of that, I set up load
> > suffixes a way, that only .elc is searched, nothing else.
>
> But that's entirely specific to your local setup. If you want to have
> all Lisp files as *.elc, and if you are certain you will never want
> Emacs to load a .el file, then just byte-compile finder-inf.el
> locally, and be done. Why do we need to make any changes in Emacs for
> such a personal problem?
>
> I can tell right away why such a change as a general feature would be
> bad: it is quite possible, perhaps even probable, that users might
> have *.el files they don't compile for some reasons, of have *.el
> files newer than the corresponding *.elc files, and we definitely
> don't want to defeat their loading just because it makes the session
> start up slower by 25 milliseconds.
>
Yes Eli, I'm definitely not advocating to turning off el losing our
changing the suffix logic in any way, because as you mentioned, that would
trip to normal use cases and that's totally unacceptable for 25
milliseconds. My honest apologies if I miscommunicated and made it sound
like that's what I'm advocating for, didn't want to criticize the emacs
team in any way of advocate for big changes like this.
What I'm asking for is just the compilation of this one file in the build
or install process (similar to all the rest), so it's available as elc if
ever needed. It of course should still be kept as el too, as the rest of
the files are kept too (when byte compiled).
The reason why this is not convenient for me to do locally: it's part of
the system packaging that I use (Debian, but I think it would be the same
with other distros). And therefore periodically new version will appear and
I'll have to remember and recompile again.
There is no risk for the end user for this elc compilation to get out of
date, as it's part of the core emacs installation, and therefore read only
on most systems. So the risk is exactly the same as for any other el files
hand modified in the system installation.
Also, I use many machines at different locations, with different emacs
versions, so it's not a one time local change and forget situation, would
be tedious to remember after each apt upgrade.
Thanks again for considering this, I'm of course happy to discuss and
explain why do I need changes in Emacs. Thanks for your continued decades
old maintenance efforts and sorry if I sounded arrogant on my first try,
was not my intention.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.