bug#24918: 25.1; Fonts can make Emacs grind to a halt

[Klaus-Dieter Bauer]

2016-11-30 4:42 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Tue, 29 Nov 2016 23:42:38 +0100
> Cc: 24918@debbugs.gnu.org
>
> Ah, I missed that line in `C-u C-x ='. (I also don't see any message from Clément).
>
> #### Using "emacs -Q" ####
>
> It says for the ⇒ (\Rightarrow) symbol
> display: by this font (glyph code)
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
>
> For the ‖ (\Vert) and ※ (\textreferencemark) symbols:
> uniscribe:-outline-MS Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x340)
>
> For the symbol:
> uniscribe:-outline-MS Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x364)
>
> #### With init file ####
>
> (using Linux Libertine Mono as default font)
>
> The ‖ and ※ symbols work fine in that configuraiton.
> "⇒" still causes the issue here too, and falls back to identically the same `uniscribe' line
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
>
> The extreme lag in `package-list-packages' seems to be caused by the ▲ symbol in the **header line**,
> which works fine with the default font, but is substituted with
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-16-*-*-*-p-*-gb2312.1980-0 (#x240)
> when using `Linux Libertine Mono' or `Noto Mono'.

I think the problem is that these fonts have registry that is not
iso10646-1 (i.e. Unicode).

Do you have Symbola installed?  I'm guessing you don't, and if so, can
you please install it?  Emacs by default is configured to use that
font for these symbols, and with the correct registry.

> By any chance, do any of your test systems run Windows and have MS Office installed? (In my case the 2010
> version.) It should be the primary source of Unicode fonts on my system.

Yes, I do on one of my machines, and I don't experience these problems
there.

I now installed Symbola. In the real-world cases it solves the problem, but apparently it is not a full solution; Possibly sufficient for practical use, but mostly more efficient at masking the issue. (See especially the example below, where the issue occurs even when no fonts are available at all for a character.)

E.g. I used 

(with-selected-window

    (display-buffer (get-buffer-create "*foo*"))

  (goto-char (point-max))

  (cl-loop for _ upto 1000 ;; lower the limit if it crashes emacs

   with lmt = (+ 1 (max-char))

   for s = (string (random lmt))

   for col = (- (point) (line-beginning-position))

   if (< 30 col) do (insert "\n")

   do (insert s)))

to generate random unicode characters; For most no font is found at all (a hex-rectangle is displayed instead) 

              display: no font available

but some characters will be generated, where problematic fonts still come up.

Additionally, one generated line was also heavily laggy, despite all characters saying "no font available", i.e. even without font substitution. I attached the line as "problematic-line.txt". Navigating into or out of this line – or from one character to the next, for about half the characters in the line, talks roughly 1 second on my system. 

For this file, behaviour with (setq inhibit-compacting-font-caches t) was also somewhat inconsistent. 

- Setting the variable to t always fixed the lag.

- Setting the variable back to nil keeps the buffer lag-free for a while, but then suddenly emacs froze completely. 

---------------------------

Since I don't know if attachments are archived, I also attach a the "problematic-line.txt" as hexl/base64 dump.

00000000: 2d2a 2d20 6d6f 6465 3a20 7465 7874 3b20  -*- mode: text;

00000010: 636f 6469 6e67 3a20 7574 662d 382d 656d  coding: utf-8-em

00000020: 6163 733b 202d 2a2d 0d0a f6be a7a9 f1b5  acs; -*-........

00000030: 8485 f888 9194 94f8 8a90 a281 f88b 908e  ................

00000040: 84f8 8a98 9a9a f686 a9be f88b 8396 b5f5  ................

00000050: ac8d 8ff8 8abe a1aa f88d a4aa 9ef3 8ab8  ................

00000060: 9cf8 8eb0 9bbf f7a7 a6ae f7a7 848b f586  ................

00000070: 93ab f280 b382 f88d 958a 9ff2 a1ac 86f8  ................

00000080: 8fa0 9784 f3b5 849b f6b7 93ae f889 b4aa  ................

00000090: a2ef a39b f88a 9b96 a4f8 8dae b4b6 f88a  ................

000000a0: a9b6 bdf3 b29f a7f8 89bb 85b5 f682 a188  ................

000000b0: f88a a0a3 810d 0a                        .......

LSotIG1vZGU6IHRleHQ7IGNvZGluZzogdXRmLTgtZW1hY3M7IC0qLQ0K9r6nqfG1hIX4iJGUlPiK

kKKB+IuQjoT4ipiamvaGqb74i4OWtfWsjY/4ir6hqviNpKqe84q4nPiOsJu/96emrvenhIv1hpOr

8oCzgviNlYqf8qGshviPoJeE87WEm/a3k674ibSqou+jm/iKm5ak+I2utLb4iqm2vfOyn6f4ibuF

tfaCoYj4iqCjgQ0K

problematic-line.txt
Description: Text document