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

[Eli Zaretskii <eliz@gnu.org>]

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Wed, 30 Nov 2016 11:01:32 +0100
> Cc: 24918@debbugs.gnu.org
> 
> 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.

Thanks.