2016-11-10 18:12 GMT+01:00 Eli Zaretskii
<eliz@gnu.org>:
> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> 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.