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

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

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


From: Klaus-Dieter Bauer
Subject: bug#24918: 25.1; Fonts can make Emacs grind to a halt
Date: Thu, 1 Dec 2016 11:21:36 +0100

2016-11-30 16:00 GMT+01:00 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.

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: Inline-Bild 3 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. 


reply via email to

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