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, 10 Nov 2016 23:05:17 +0100


2016-11-10 18:12 GMT+01:00 Eli Zaretskii <address@hidden>:
> From: Klaus-Dieter Bauer <address@hidden>
> Date: Thu, 10 Nov 2016 16:53:55 +0100
>
> When using Google's "Noto Mono" font, some buffers grind to a halt, with
> user input being registered with roughly a one-second delay. Trying to
> do more, will make Emacs entirely unresponsive to user-input leaving
> only killing the process through the task manager (Windows 10,
> tasgmgr.exe or 'taskkill /F /IM emacs.exe').
>
> To avoid interaction with other customizations I tried it with
https://ftp.gnu.org/gnu/emacs/windows/emacs-25.1-x86_64-w64-mingw32.zip
> starting emacs as 'runemacs -Q' and observed the same behavior.
>
> The issue is dodgy though. The only case where I could consistently
> reproduce it, was `package-list-packages' (using ELPA only). When saving
> the buffer contents as a text file and opening it, the issue did *not*
> occur.
>
> Outside of Emacs I haven't yet observed issues with the Noto fonts.
>
> The user-side fix (using another font) is easy, but the font being the blame
> was rather unexpected.

If you can build your own Emacs, please build the emacs-25 branch of
the Emacs Git repository, and see if setting the new variable
inhibit-compacting-font-caches to non-nil solves this.

Thanks.

I (accidentially) built 26.0.50.1 (x86_64-w64-mingw32) instead of the emacs-25 branch.

Anyway, there it worked. Without `inhibit-compating-font-caches' it would show the same behaviour as before in `package-list-packages', setting the variable to t the problem vanished.


reply via email to

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