bug#50934: 28.0.60; paren.el should be preloaded

bug#50934: 28.0.60; paren.el should be preloaded

[Eli Zaretskii]

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))

bug#50934: 28.0.60; paren.el should be preloaded

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#50934: 28.0.60; paren.el should be preloaded

[Eli Zaretskii]

> Date: Fri, 01 Oct 2021 13:49:31 +0300
> From: Eli Zaretskii <eliz@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?

bug#50934: 28.0.60; paren.el should be preloaded

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#50934: 28.0.60; paren.el should be preloaded

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 01 Oct 2021 13:49:31 +0300
>> From: Eli Zaretskii <eliz@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

bug#50934: 28.0.60; paren.el should be preloaded

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 50934@debbugs.gnu.org
> Date: Fri, 01 Oct 2021 13:11:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Fri, 01 Oct 2021 13:49:31 +0300
> >> From: Eli Zaretskii <eliz@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.

bug#50934: 28.0.60; paren.el should be preloaded

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 50934@debbugs.gnu.org
>> Date: Fri, 01 Oct 2021 13:11:33 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Fri, 01 Oct 2021 13:49:31 +0300
>> >> From: Eli Zaretskii <eliz@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

bug#50934: 28.0.60; paren.el should be preloaded

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 50934@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.

bug#50934: 28.0.60; paren.el should be preloaded

[Eli Zaretskii]

> Date: Sat, 02 Oct 2021 11:13:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 50934@debbugs.gnu.org
> 
> > From: Andrea Corallo <akrl@sdf.org>
> > Cc: 50934@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.