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

From: Klaus-Dieter Bauer <[email-masked]>
Date: Thu, 1 Dec 2016 11:21:36 +0100

2016-11-30 16:00 GMT+01:00 Eli Zaretskii <[email-masked]>:

> > From: Klaus-Dieter Bauer <[email-masked]>
> > Date: Wed, 30 Nov 2016 11:01:32 +0100
> > Cc: [email-masked]
> >
> > 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.
>
> If you need those characters to be displayed faster, you need to
> configure your default fontset to cover them with Unicode fonts.  The
> default fontset setup in Emacs tries not to get in the way of users
> with too many special fonts, so not all the ranges are covered, unless
> there are good free fonts for them.
>
> > 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.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

These characters are all unassigned codepoints (i.e., Unicode did not
> yet assign any characters to those codepoints), as you can see in the
> buffer shown by "C-u C-x =", so their display are not important in any
> practical use case.
>

Thankfully, yes. I meant this to be a testcase for checking if their is an
underlying issue beyond font substitution, which I assumed this example
indicated, since no font was substituted.

Anyway, I figured out that the particular character that caused the issue
for *this* file was "(insert (string #xF8DB))", which in Gnu Unifont is
displayed as a pencil:  Apparently it is in a
"private use" block though.

Would it be possible to distribute Symbola along with Emacs for the Windows
version, or some other viable unicode fallback font such as GNU Unifont
(which by the way also fixes the "random characters" test case)?
Program-crashes from unexpected characters, let alone from visiting
info-page buffers, definitely shouldn't be out-of-the-box behaviour, and
apparently appropriate fonts cannot be safely assumed on Windows.