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

[Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4892 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 7445 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: problematic-line.txt --]
[-- Type: text/plain; charset=CP932; name="problematic-line.txt", Size: 183 bytes --]

-*- mode: text; coding: utf-8-emacs; -*-
ö¾§©ñµ„…øˆ‘””øŠ¢ø‹Ž„øŠ˜ššö†©¾ø‹ƒ–µõ¬øŠ¾¡ªø¤ªžóŠ¸œøŽ°›¿÷§¦®÷§„‹õ†“«ò€³‚ø•ŠŸò¡¬†ø —„󵄛ö·“®ø‰´ª¢ï£›øŠ›–¤ø®´¶øŠ©¶½ó²Ÿ§ø‰»…µö‚¡ˆøŠ £