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

[Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2308 bytes --]