GNU bug report logs - #40733
28.0.50; Emacs locks up on paste (yank) of unicode characters

Previous Next

Package: emacs;

Reported by: Will Bush <will.g.bush <at> gmail.com>

Date: Mon, 20 Apr 2020 14:56:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Will Bush <will.g.bush <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org,
 James Cloos <cloos <at> jhcloos.com>
Subject: Re: bug#40733: 28.0.50;
 Emacs locks up on paste (yank) of unicode characters
Date: Sat, 25 Apr 2020 05:34:23 -0500
[Message part 1 (text/plain, inline)]
Robert> Which font specifically does emacs end up using for that character?
Robert> Emacs ends up using 'Noto Sans CJK KR' for me here.

When google fonts is removed?

This is what `C-u C-x =` says:

ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1
(#xDD38ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1
(#xDD38)

Note on the above: For the hell of it, I tried installing `noto-fonts` font
pack
from nixpkgs and it didn't make a difference. Then again, `fc-list
--verbose |
rg "Noto Sans CJK" -i` produced no results so that specific font probably
isn't
in that font pack.

When google fonts are installed:

ftcrhb:-GNU-Unifont-normal-normal-normal-Sans-Serif-16-*-*-*-c-80-iso10646-1
(#xDD36)

Robert> BTW, if you want to ignore that font, you can set
Robert> 'face-ignored-fonts' to match it, and you won't have to uninstall
it.

Thanks, I didn't know that! Maybe I can use that to narrow down to the
specific
font that's causing problems because adding `google-fonts` adds 2905 fonts
for
me, and many I would like to have.

Robert> I donʼt think thereʼs much point in that: emacs-26 uses Xft for font
Robert> handling, emacs-27 uses Cairo+Harfbuzz[1]; theyʼre fundamentally
doing
Robert> very different things, so I donʼt think this is caused by a single
Robert> identifiable change.

I'm not trying to prove you wrong or anything. It's just easy for me to try
different versions because I'm using
(https://github.com/nix-community/emacs-overlay). However, I tried Emacs
27.0.50
and it's behaving exactly the same as Emacs 26. I glanced at the
`report-emacs-bug` output and the build inputs look the same. I can include
it
if desired.

λ ~/ time emacs -Q --eval '(message "hi")' -kill
emacs -Q --eval '(message "hi")' -kill  0.18s user 0.02s system 67% cpu
0.303 total
λ ~/ time emacs -Q --eval '(message "︵")' -kill
emacs -Q --eval '(message "︵")' -kill  0.44s user 0.03s system 95% cpu
0.494 total
λ ~/ emacs --version
GNU Emacs 27.0.50

Robert> ...we implicitly do '--with-cairo' now.

Is that since 27.0.50?

Were either Cairo+Harfbuzz libraries updated since 27.0.50 (perhaps a
regression
in those libraries)? I'll follow up with an update later after testing more
versions.

Robert> Although you can still build it with Xft if you want, but I
Robert> wouldnʼt recommend that, since it will crash once you start
Robert> processing Emojis and other 'interesting' Unicode characters.

Just to verity I understand. Building with Xft is what `--with-xft` is
doing in
the following from my initial email?

Configured using:
 'configure
 --prefix=/nix/store/5v0fp6vikajaqc2v0ppkm51hfc054mnm-emacs-git-20190910.0
 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
 CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'

Eli> I'm not sure I understand: you are saying that slow, but correct
Eli> display is _worse_ than displaying a white space instead of the
Eli> correct glyph, i.e. producing incorrect display?  To me, it sounds
Eli> like Emacs 27+ actually _improves_ things in this case.

Let me quantify the performance because I've been ambiguous about it so far:

λ ~/ time emacs -Q --eval '(message "hi")' -kill
emacs -Q --eval '(message "hi")' -kill  0.19s user 0.02s system 55% cpu
0.371 total
λ ~/ time emacs -Q --eval '(message "︵")' -kill
emacs -Q --eval '(message "︵")' -kill  81.64s user 0.03s system 99% cpu
1:21.91 total

It takes ~81 seconds to do something while locking up the UI. That's
personally
beyond my threshold for killing the process.


On Wed, Apr 22, 2020 at 2:35 AM Robert Pluim <rpluim <at> gmail.com> wrote:

> >>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos <at> jhcloos.com>
> said:
>
> >>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
>     RP> Footnotes:
>     RP> [1]  Although you can still build it with Xft if you want, but I
>     RP> wouldnʼt recommend that, since it will crash once you start
>     RP> processing Emojis and other 'interesting' Unicode characters.
>
>     James> note that master will also crash when using cr+hb on some code
> points.
>
>     James> such as some private use characters.
>
> Examples? Eli fixed one such case with Bug#39892, but if there are
> more we should fix them (please open a separate bug report for that).
>
> Robert
>
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 28 days ago.

Previous Next


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