GNU bug report logs - #65908
29.1.50; Emacs 29 regresses on macOS

Previous Next

Package: emacs;

Reported by: Zhang Haijun <ccsmile2008 <at> outlook.com>

Date: Wed, 13 Sep 2023 06:48:02 UTC

Severity: normal

Found in version 29.1.50

Fixed in version 29.2

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: gerd.moellmann <at> gmail.com, gregory <at> heytings.org, 65908 <at> debbugs.gnu.org, stefankangas <at> gmail.com, ccsmile2008 <at> outlook.com
Subject: bug#65908: 29.1.50; Emacs 29 regresses on macOS
Date: Thu, 05 Oct 2023 08:41:28 +0300
> Date: Wed, 4 Oct 2023 22:16:22 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,
> 	Gregory Heytings <gregory <at> heytings.org>, 65908 <at> debbugs.gnu.org,
> 	Eli Zaretskii <eliz <at> gnu.org>, ccsmile2008 <at> outlook.com
> 
> On Wed, Oct 04, 2023 at 02:43:05PM +0200, Gerd Möllmann wrote:
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> > 
> > > Stefan Kangas <stefankangas <at> gmail.com> writes:
> > >
> > >>> I try to update the list of failing commits monthly.
> > >>
> > >> Thanks for maintaining that script.  We need more people showing that
> > >> kind of initiative and drive.
> > >
> > > +1
> > >
> > > And, three weeks later, the culprit is
> > >
> > > commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD)
> > > Author: Alan Third <alan <at> idiocy.org>
> > > Date:   Sun Nov 14 15:09:43 2021 +0000
> > >
> > >     Only set LANG if the ID is valid
> > >     
> > >     * src/nsterm.m (ns_init_locale): Check the provided locale identifier
> > >     is available before trying to use it.
> > >
> > > But don't ask me how that comes into play here because that function
> > > seems to be called from main only.  Maybe it's because LANG is now not
> > > always set, but used somewhere else?
> 
> AFAIK LANG isn't used by Emacs at all. That code is just there to help
> set up a default environment for running shell commands.
> 
> > As an experiment, I evaluated this in *scratch*:
> > 
> > (setenv "LANG" "")
> > (setenv "LC_COLLATE" "C")
> > (setenv "LC_CTYPE" "UTF-8")
> > (setenv "LC_MESSAGES" "C")
> > (setenv "LC_MONETARY" "C")
> > (setenv "LC_NUMERIC" "C")
> > (setenv "LC_TIME" "C")
> > 
> > which is the output of 'locale' in a terminal, translated to Elisp.
> > With these settings, the slowdown is gone, without changing the code.
> 
> So is Emacs run in the terminal with a LANG of something like
> en_GB.UTF-8 slower too? Because iirc my mac's terminal doesn't default
> to 'C' and I don't see anything GUI specific in the test code...
> 
> FWIW I don't see any meaningful difference using different locale
> settings on my Debian box, which makes me wonder if there is some
> low-level darwin code that reads the locale from the environment. Any
> idea if it's loading the files or stepping through the defuns that's
> slower, or both?
> 
> Long story short: I have no idea what's going on here.

Crystal ball says that the UTF-8 locale turns on some expensive
processing where it doesn't happen with the C locale.  One potential
place is case-insensitive comparisons and such likes.

Selectively setting only some of the LC_* variables limits the
expensive processing only to some operations.

In general, Emacs only needs to locale's settings to decide which
locale-environment and language-environment to turn on, all the rest
we do by ourselves.




This bug report was last modified 1 year and 226 days ago.

Previous Next


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