GNU bug report logs - #50934
28.0.60; paren.el should be preloaded

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50934 in the body.
You can then email your comments to 50934 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 13:49:31 +0300

Since show-paren-mode is now ON by default, whenever Emacs starts it
now loads paren.elc? during startup.  So I think we should now preload
paren.el.


In GNU Emacs 28.0.60 (build 2, i686-pc-mingw32)
 of 2021-10-01 built on HOME-C4E4A596F7
Repository revision: 94c247d65978c204c51c829e6b03b651d5bbd454
Repository branch: emacs-28
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
paren iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 56890 9622)
 (symbols 48 7826 1)
 (strings 16 21715 2918)
 (string-bytes 1 634358)
 (vectors 16 13672)
 (vector-slots 8 180294 11153)
 (floats 8 24 45)
 (intervals 40 266 93)
 (buffers 888 10))

Message #8 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50934 <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 14:35:26 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Since show-paren-mode is now ON by default, whenever Emacs starts it
> now loads paren.elc? during startup.  So I think we should now preload
> paren.el.

Makes sense to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 50934 <at> debbugs.gnu.org
Cc: Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 15:55:33 +0300

> Date: Fri, 01 Oct 2021 13:49:31 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Since show-paren-mode is now ON by default, whenever Emacs starts it
> now loads paren.elc? during startup.  So I think we should now preload
> paren.el.

One consequence of paren.el's not being preloaded is that in a
native-compilation build, Emacs begins compiling paren.el as soon as
it starts, and that causes it also to compile about a dozen other
files that comp.el requires.  Should we perhaps native-compile all the
prerequisites of comp.el as part of COMPILE_FIRST when we build Emacs?

Message #14 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50934 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 14:57:39 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> One consequence of paren.el's not being preloaded is that in a
> native-compilation build, Emacs begins compiling paren.el as soon as
> it starts, and that causes it also to compile about a dozen other
> files that comp.el requires.  Should we perhaps native-compile all the
> prerequisites of comp.el as part of COMPILE_FIRST when we build Emacs?

I think that's a good idea.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50934 <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 13:11:33 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 01 Oct 2021 13:49:31 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> Since show-paren-mode is now ON by default, whenever Emacs starts it
>> now loads paren.elc? during startup.  So I think we should now preload
>> paren.el.
>
> One consequence of paren.el's not being preloaded is that in a
> native-compilation build, Emacs begins compiling paren.el as soon as
> it starts, and that causes it also to compile about a dozen other
> files that comp.el requires.  Should we perhaps native-compile all the
> prerequisites of comp.el as part of COMPILE_FIRST when we build Emacs?

I think we should keep an eye on the build time impact of this.  If I'm
not mistaken native compiling COMPILE_FIRST targets is slower than
afterward cause comp.el and friends are running interpreted.

  Andrea

Message #20 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 50934 <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 16:17:00 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 50934 <at> debbugs.gnu.org
> Date: Fri, 01 Oct 2021 13:11:33 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Fri, 01 Oct 2021 13:49:31 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >> 
> >> Since show-paren-mode is now ON by default, whenever Emacs starts it
> >> now loads paren.elc? during startup.  So I think we should now preload
> >> paren.el.
> >
> > One consequence of paren.el's not being preloaded is that in a
> > native-compilation build, Emacs begins compiling paren.el as soon as
> > it starts, and that causes it also to compile about a dozen other
> > files that comp.el requires.  Should we perhaps native-compile all the
> > prerequisites of comp.el as part of COMPILE_FIRST when we build Emacs?
> 
> I think we should keep an eye on the build time impact of this.  If I'm
> not mistaken native compiling COMPILE_FIRST targets is slower than
> afterward cause comp.el and friends are running interpreted.

The native-compilation build is already painfully slow, and most of it
isn't spent in COMPILE_FIRST.  We could, of course, add those files to
shortlisp instead, if you think this is better.

Message #23 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50934 <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 01 Oct 2021 13:35:57 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 50934 <at> debbugs.gnu.org
>> Date: Fri, 01 Oct 2021 13:11:33 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Date: Fri, 01 Oct 2021 13:49:31 +0300
>> >> From: Eli Zaretskii <eliz <at> gnu.org>
>> >> 
>> >> Since show-paren-mode is now ON by default, whenever Emacs starts it
>> >> now loads paren.elc? during startup.  So I think we should now preload
>> >> paren.el.
>> >
>> > One consequence of paren.el's not being preloaded is that in a
>> > native-compilation build, Emacs begins compiling paren.el as soon as
>> > it starts, and that causes it also to compile about a dozen other
>> > files that comp.el requires.  Should we perhaps native-compile all the
>> > prerequisites of comp.el as part of COMPILE_FIRST when we build Emacs?
>> 
>> I think we should keep an eye on the build time impact of this.  If I'm
>> not mistaken native compiling COMPILE_FIRST targets is slower than
>> afterward cause comp.el and friends are running interpreted.
>
> The native-compilation build is already painfully slow, and most of it
> isn't spent in COMPILE_FIRST.  We could, of course, add those files to
> shortlisp instead, if you think this is better.

I suspect shortlisp might be a better option (the number of threads of
the machine here comes into play as well), but I guess a measure is the
only way to get an answer.  IOW just wanted to raise the warning.

Regards

  Andrea

Message #26 received at 50934 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 50934 <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Sat, 02 Oct 2021 11:13:45 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 50934 <at> debbugs.gnu.org
> Date: Fri, 01 Oct 2021 13:35:57 +0000
> 
> > The native-compilation build is already painfully slow, and most of it
> > isn't spent in COMPILE_FIRST.  We could, of course, add those files to
> > shortlisp instead, if you think this is better.
> 
> I suspect shortlisp might be a better option (the number of threads of
> the machine here comes into play as well), but I guess a measure is the
> only way to get an answer.  IOW just wanted to raise the warning.

I tried to add these to shortlisp, after the value is exported as
$LISP_PRELOADED, but that didn't work: the added files were only
byte-compiled, not ELC+ELN-compiled.  I cannot figure out why this
happens.  I think this mystery should be resolved, so we would know
how to add files to AOT native compilation without adding them to
COMPILE_FIRST and without putting them into preloaded/.  I also cannot
figure out how come some files not mentioned in shortlisp end up being
ELC+ELN-compiled (for example emoji-zwj.el), also something that's
worth understanding.

For now, I just added those files to COMPILE_FIRST.

Thanks.

Message #31 received at 50934-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: akrl <at> sdf.org
Cc: 50934-done <at> debbugs.gnu.org
Subject: Re: bug#50934: 28.0.60; paren.el should be preloaded
Date: Fri, 08 Oct 2021 14:26:47 +0300

> Date: Sat, 02 Oct 2021 11:13:45 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 50934 <at> debbugs.gnu.org
> 
> > From: Andrea Corallo <akrl <at> sdf.org>
> > Cc: 50934 <at> debbugs.gnu.org
> > Date: Fri, 01 Oct 2021 13:35:57 +0000
> > 
> > > The native-compilation build is already painfully slow, and most of it
> > > isn't spent in COMPILE_FIRST.  We could, of course, add those files to
> > > shortlisp instead, if you think this is better.
> > 
> > I suspect shortlisp might be a better option (the number of threads of
> > the machine here comes into play as well), but I guess a measure is the
> > only way to get an answer.  IOW just wanted to raise the warning.
> 
> I tried to add these to shortlisp, after the value is exported as
> $LISP_PRELOADED, but that didn't work: the added files were only
> byte-compiled, not ELC+ELN-compiled.  I cannot figure out why this
> happens.  I think this mystery should be resolved, so we would know
> how to add files to AOT native compilation without adding them to
> COMPILE_FIRST and without putting them into preloaded/.  I also cannot
> figure out how come some files not mentioned in shortlisp end up being
> ELC+ELN-compiled (for example emoji-zwj.el), also something that's
> worth understanding.
> 
> For now, I just added those files to COMPILE_FIRST.

The problem is solved, so I'm marking the bug done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.