bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25279: 26.0.50; Slowdown/crash on certain characters


From: Eli Zaretskii
Subject: bug#25279: 26.0.50; Slowdown/crash on certain characters
Date: Mon, 26 Dec 2016 22:25:44 +0200

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 26 Dec 2016 20:09:16 +0000
> 
> >From emacs -Q:
> Insert MUSIC FLAT SIGN or RIGHTWARDS DOUBLE ARROW in a buffer.
> Move point around in the buffer or edit the buffer text.
> Emacs gets very slow, consuming a lot of CPU.
> Sometimes it completely grinds to a halt.

Doesn't happen here.

> MUSIC FLAT SIGN and RIGHTWARDS DOUBLE ARROW are examples
> that cause this problem for me. MUSIC SHARP SIGN and
> RIGHTWARDS ARROW are examples that do not cause a problem.
> 
> Below are the contents of the describe-char buffer for these
> characters (with the character itself asterisked out in each
> case so as not to crash my Emacs while I edit this mail).
> 
> Note the categories. They seem illogical. Are they supposed
> to be like that? Why?

Because you don't have Symbola installed, I guess.  The fonts Emacs
finds for displaying these characters all have non-Unicode registry
fields, and that causes Emacs to desperately look for a Unicode font
each time it needs to display one of these characters.

Symbola is referenced in the default fontset with Unicode registry.
You could also customize the fontset with the fonts you have, giving
them iso10646-1 as the registry instead of what you have now, and that
might also fix the problem.  But installing Symbola is better, IMO.

Alternatively, setting inhibit-compacting-font-caches to a non-nil
value will probably work around the problem.

> Note the fonts. Could there be a bug in "Malgun Gothic"?
> As far as I know it's a Korean font installed by default with Windows.
> Could there be a bug in "Consolas"? Why does Emacs find the MUSIC
> SHARP SIGN glyph but not the MUSIC FLAT SIGN glyph from Consolas?

You will need to look into the coverage of these fonts to answer those
questions, I think.  On Windows, Emacs generally examines fonts in the
alphabetical order, looking for the first font that supports the
character, and that's after it tried to use the default face's font.

> I asked about this on IRC and there exist Windows Emacs users who
> don't have the issue, so it may be influenced by environmental
> factors.

Those factors are the fonts they have installed, I think.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]