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

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

[Klaus-Dieter Bauer]

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

Hello!

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.

regards, Klaus



In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: DEA
  locale-coding-system: cp1252

Major mode: Package Menu

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Mark set [4 times]
You can run the command ‘package-list-packages’ with M-x pa-l- RET
Package refresh done
Mark set
Quit
user-error: Saving settings from "emacs -q" would overwrite existing
customizations
Mark set
user-error: Saving settings from "emacs -q" would overwrite existing
customizations
Package refresh done
C-x C-g is undefined

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail crm thingatpt cus-edit
cus-start cus-load wid-edit warnings mm-archive message dired
format-spec rfc822 mml mml-sec epg mailabbrev gmm-utils mailheader
mm-decode mm-bodies mm-encode url-handlers mail-utils network-stream nsm
starttls url-http tls gnutls mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-gw url-cache url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source cl-seq eieio eieio-core cl-macs gnus-util mm-util
help-fns mail-prsvr password-cache url-vars mailcap finder-inf package
epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode
easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 16 178349 20495)
 (symbols 56 24138 0)
 (miscs 48 554 679)
 (strings 32 31726 4513)
 (string-bytes 1 843950)
 (vectors 16 18272)
 (vector-slots 8 495355 7739)
 (floats 8 245 115)
 (intervals 56 6280 29)
 (buffers 976 24))

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

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 4518 bytes --]

Hi,

Could this be bug 21028? (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21028)

Cheers,
Clément.

On 2016-11-10 10:53, Klaus-Dieter Bauer wrote:
> Hello!
> 
> 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. 
> 
> regards, Klaus
> 
> 
> 
> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>  of 2016-09-17 built on LAPHROAIG
> Windowing system distributor 'Microsoft Corp.', version 10.0.14393
> Configured using:
>  'configure --without-dbus --without-compress-install CFLAGS=-static'
> 
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
> TOOLKIT_SCROLL_BARS
> 
> Important settings:
>   value of $LANG: DEA
>   locale-coding-system: cp1252
> 
> Major mode: Package Menu
> 
> Minor modes in effect:
>   tooltip-mode: t
>   global-eldoc-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   buffer-read-only: t
>   line-number-mode: t
>   transient-mark-mode: t
> 
> Recent messages:
> Mark set [4 times]
> You can run the command ‘package-list-packages’ with M-x pa-l- RET
> Package refresh done
> Mark set
> Quit
> user-error: Saving settings from "emacs -q" would overwrite existing customizations
> Mark set
> user-error: Saving settings from "emacs -q" would overwrite existing customizations
> Package refresh done
> C-x C-g is undefined
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort mail-extr emacsbug sendmail crm thingatpt cus-edit
> cus-start cus-load wid-edit warnings mm-archive message dired
> format-spec rfc822 mml mml-sec epg mailabbrev gmm-utils mailheader
> mm-decode mm-bodies mm-encode url-handlers mail-utils network-stream nsm
> starttls url-http tls gnutls mail-parse rfc2231 rfc2047 rfc2045
> ietf-drums url-gw url-cache url-auth url url-proxy url-privacy
> url-expand url-methods url-history url-cookie url-domsuf url-util
> url-parse auth-source cl-seq eieio eieio-core cl-macs gnus-util mm-util
> help-fns mail-prsvr password-cache url-vars mailcap finder-inf package
> epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode
> easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util tooltip
> eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
> dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd
> fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
> lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
> scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
> cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
> tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
> slovak czech european ethiopic indian cyrillic chinese charscript
> case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
> cl-preloaded nadvice loaddefs button faces cus-face macroexp files
> text-properties overlay sha1 md5 base64 format env code-pages mule
> custom widget hashtable-print-readable backquote w32notify w32 multi-tty
> make-network-process emacs)
> 
> Memory information:
> ((conses 16 178349 20495)
>  (symbols 56 24138 0)
>  (miscs 48 554 679)
>  (strings 32 31726 4513)
>  (string-bytes 1 843950)
>  (vectors 16 18272)
>  (vector-slots 8 495355 7739)
>  (floats 8 245 115)
>  (intervals 56 6280 29)
>  (buffers 976 24))
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eli Zaretskii]

> 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.

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

[Klaus-Dieter Bauer]

[-- 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 --]

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

[Eli Zaretskii]

unarchive 24565 15876
close 24918
merge 24918 24565
archive 24565 24918 15876
thanks

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Thu, 10 Nov 2016 23:05:17 +0100
> Cc: 24918@debbugs.gnu.org
> 
>  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.

Doesn't matter, the fix exists on both branches.

> 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.

Thanks for testing.  This means Emacs 25.2 will have a solution for
this problem, and so I'm closing this report and merging it with
bug#24565 where this was solved.

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

[Eli Zaretskii]

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Sun, 27 Nov 2016 22:12:48 +0100
> Cc: 24918@debbugs.gnu.org
> 
> I tried compiling the emacs-25 branch , freshly cloned (25.1.50.1) and ran it as "emacs -Q". I hope that is the
> version you meant. 
> 
> The issue persists unless setting (setq inhibit-compacting-font-caches t), as before.
> 
> It can be reproduced by scrolling (with mouse or keyboard) in info node `(cl) Structures'. If scrolling fast, such
> that the multiple input events queue up while Emacs is hanging, Emacs freezes permanently and has to be
> killed. 

Is this because you use the Noto Mono font, or is this with the
default fonts?  If the latter, please show how you customized Emacs to
use Noto Mono.

Thanks.

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

[Klaus-Dieter Bauer]

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

The issue occurs with the default fonts too ("emacs -Q"). On Windows that
means `Courier New' for `default' and `Monospace' for `fixed-pitch',
`Monospace Serif` for `fixed-pitch-serif' and `Arial` for `variable-pitch'.

With these default settings, the `package-list-packages' buffer works
mostly fine, but the info page `(cl) Structures' for instace does not.
Using different fonts, e.g. `Linux Libertine Mono' or `Noto Mono', the
issue becomes only more widespread.

I detail, I noticed that the issue indeed does occur specifically *when
font substitution kicks in*. In the info-page for `(cl) Structure' this
occurs, because the "=>" is replaced by the unicode symbol "⇒", which is
displayed in a different font; Sadly I can't figure out a way to identify
the substituted font; It is definitely a variable-pitch font (the symbol is
wider than the default font, such that characters are no longer vertically
aligned with other lines).

For such font-substituted characters, there are multiple cases where I
observed delays.

   1. When the character becomes visible in the current window (small delay
   if caused by a single input event, but can crash Emacs when
   scrolling-events, and thus delays, queue up).
   2. When `point' is moved to the line containing the character, either
   with mouse or keyboard (somewhat bigger delay).
   3. When `point' is moved to the character itself, either with mouse or
   keyboard (extensive delay).
   4. Whenever there is any change to the Window-layout (e.g. splitting the
   window, or resizing the frame).

My guess would be that custom fonts only make the issue more apparent,
because font-substitution may become more widespread.

If there is any possibility to identify the font used in font substitution
(it doesn't affect the text-attributes apparently, so C-u C-x = doesn't
help), I could check if the issue is related to one of the fonts I have
installed on my system.

- Klaus


2016-11-28 16:47 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> > Date: Sun, 27 Nov 2016 22:12:48 +0100
> > Cc: 24918@debbugs.gnu.org
> >
> > I tried compiling the emacs-25 branch , freshly cloned (25.1.50.1) and
> ran it as "emacs -Q". I hope that is the
> > version you meant.
> >
> > The issue persists unless setting (setq inhibit-compacting-font-caches
> t), as before.
> >
> > It can be reproduced by scrolling (with mouse or keyboard) in info node
> `(cl) Structures'. If scrolling fast, such
> > that the multiple input events queue up while Emacs is hanging, Emacs
> freezes permanently and has to be
> > killed.
>
> Is this because you use the Noto Mono font, or is this with the
> default fonts?  If the latter, please show how you customized Emacs to
> use Noto Mono.
>
> Thanks.
>

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

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

On 2016-11-29 05:29, Klaus-Dieter Bauer wrote:
> If there is any possibility to identify the font used in font
> substitution (it doesn't affect the text-attributes apparently, so
> C-u C-x = doesn't help).

It does, actually; look at the last line ("display") of the header.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eli Zaretskii]

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Tue, 29 Nov 2016 11:29:03 +0100
> Cc: 24918@debbugs.gnu.org
> 
> The issue occurs with the default fonts too ("emacs -Q"). On Windows that means `Courier New' for `default'
> and `Monospace' for `fixed-pitch', `Monospace Serif` for `fixed-pitch-serif' and `Arial` for `variable-pitch'. 
> 
> With these default settings, the `package-list-packages' buffer works mostly fine, but the info page `(cl)
> Structures' for instace does not. Using different fonts, e.g. `Linux Libertine Mono' or `Noto Mono', the issue
> becomes only more widespread.
> 
> I detail, I noticed that the issue indeed does occur specifically when font substitution kicks in. In the info-page
> for `(cl) Structure' this occurs, because the "=>" is replaced by the unicode symbol "⇒", which is displayed in
> a different font; Sadly I can't figure out a way to identify the substituted font; It is definitely a variable-pitch font
> (the symbol is wider than the default font, such that characters are no longer vertically aligned with other
> lines). 

That's very strange, because I see nothing similar on my systems.

As Clément points out, "C-u C-x =" will show the font that is used to
display those characters.  Please tell what they are; they use Symbola
here (and that's how things should be, by default).

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

[Klaus-Dieter Bauer]

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

2016-11-29 18:47 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> > Date: Tue, 29 Nov 2016 11:29:03 +0100
> > Cc: 24918@debbugs.gnu.org
> >
> > The issue occurs with the default fonts too ("emacs -Q"). On Windows
> that means `Courier New' for `default'
> > and `Monospace' for `fixed-pitch', `Monospace Serif` for
> `fixed-pitch-serif' and `Arial` for `variable-pitch'.
> >
> > With these default settings, the `package-list-packages' buffer works
> mostly fine, but the info page `(cl)
> > Structures' for instace does not. Using different fonts, e.g. `Linux
> Libertine Mono' or `Noto Mono', the issue
> > becomes only more widespread.
> >
> > I detail, I noticed that the issue indeed does occur specifically when
> font substitution kicks in. In the info-page
> > for `(cl) Structure' this occurs, because the "=>" is replaced by the
> unicode symbol "⇒", which is displayed in
> > a different font; Sadly I can't figure out a way to identify the
> substituted font; It is definitely a variable-pitch font
> > (the symbol is wider than the default font, such that characters are no
> longer vertically aligned with other
> > lines).
>
> That's very strange, because I see nothing similar on my systems.
>
> As Clément points out, "C-u C-x =" will show the font that is used to
> display those characters.  Please tell what they are; they use Symbola
> here (and that's how things should be, by default).
>


Ah, I missed that line in `C-u C-x ='. (I also don't see any message from
Clément).


#### Using "emacs -Q" ####

It says for the ⇒ (\Rightarrow) symbol
              display: by this font (glyph code)
    uniscribe:-outline-Malgun
Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)

For the ‖ (\Vert) and ※ (\textreferencemark) symbols:
    uniscribe:-outline-MS
Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x340)

For the  symbol:
    uniscribe:-outline-MS
Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x364)


#### With init file ####

(using Linux Libertine Mono as default font)

The ‖ and ※ symbols work fine in that configuraiton.
"⇒" still causes the issue here too, and falls back to identically the same
`uniscribe' line
    uniscribe:-outline-Malgun
Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)

The extreme lag in `package-list-packages' seems to be caused by the ▲
symbol in the **header line**, which works fine with the default font, but
is substituted with
    uniscribe:-outline-Malgun
Gothic-normal-normal-normal-sans-16-*-*-*-p-*-gb2312.1980-0 (#x240)
when using `Linux Libertine Mono' or `Noto Mono'.


By any chance, do any of your test systems run Windows and have MS Office
installed? (In my case the 2010 version.) It should be the primary source
of Unicode fonts on my system.

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

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

[Alan Third]

On Tue, Nov 29, 2016 at 11:29:03AM +0100, Klaus-Dieter Bauer wrote:
> For such font-substituted characters, there are multiple cases where I
> observed delays.
> 
>    1. When the character becomes visible in the current window (small delay
>    if caused by a single input event, but can crash Emacs when
>    scrolling-events, and thus delays, queue up).
>    2. When `point' is moved to the line containing the character, either
>    with mouse or keyboard (somewhat bigger delay).
>    3. When `point' is moved to the character itself, either with mouse or
>    keyboard (extensive delay).
>    4. Whenever there is any change to the Window-layout (e.g. splitting the
>    window, or resizing the frame).

I experience these slow‐downs too on my work (Windows 10) PC.

I found that I could reduce the delays by defining fallback
fonts explicitly using:

    (set-face-attribute 'default nil :font "Droid Sans Mono")
    (set-fontset-font nil 'unicode "DejaVu Sans" nil 'append)
    (set-fontset-font nil 'unicode "Courier New" nil 'append)
    (set-fontset-font nil 'unicode "Symbola" nil 'append)

but it doesn’t get rid of them completely.

Switching to the new optimized Emacs 25 build improved things a bit
too, unsurprisingly.
-- 
Alan Third

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

[Eli Zaretskii]

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Tue, 29 Nov 2016 23:42:38 +0100
> Cc: 24918@debbugs.gnu.org
> 
> Ah, I missed that line in `C-u C-x ='. (I also don't see any message from Clément). 
> 
> #### Using "emacs -Q" ####
> 
> It says for the ⇒ (\Rightarrow) symbol
> display: by this font (glyph code)
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
> 
> For the ‖ (\Vert) and ※ (\textreferencemark) symbols:
> uniscribe:-outline-MS Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x340)
> 
> For the symbol:
> uniscribe:-outline-MS Gothic-normal-normal-normal-mono-17-*-*-*-c-*-gb2312.1980-0 (#x364)
> 
> #### With init file #### 
> 
> (using Linux Libertine Mono as default font)
> 
> The ‖ and ※ symbols work fine in that configuraiton. 
> "⇒" still causes the issue here too, and falls back to identically the same `uniscribe' line
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
> 
> The extreme lag in `package-list-packages' seems to be caused by the ▲ symbol in the **header line**,
> which works fine with the default font, but is substituted with 
> uniscribe:-outline-Malgun Gothic-normal-normal-normal-sans-16-*-*-*-p-*-gb2312.1980-0 (#x240)
> when using `Linux Libertine Mono' or `Noto Mono'.

I think the problem is that these fonts have registry that is not
iso10646-1 (i.e. Unicode).

Do you have Symbola installed?  I'm guessing you don't, and if so, can
you please install it?  Emacs by default is configured to use that
font for these symbols, and with the correct registry.

> By any chance, do any of your test systems run Windows and have MS Office installed? (In my case the 2010
> version.) It should be the primary source of Unicode fonts on my system. 

Yes, I do on one of my machines, and I don't experience these problems
there.

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

[Klaus-Dieter Bauer]

[-- Attachment #1.1: Type: text/plain, Size: 4892 bytes --]

2016-11-30 4:42 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> > Date: Tue, 29 Nov 2016 23:42:38 +0100
> > Cc: 24918@debbugs.gnu.org
> >
> > Ah, I missed that line in `C-u C-x ='. (I also don't see any message
> from Clément).
> >
> > #### Using "emacs -Q" ####
> >
> > It says for the ⇒ (\Rightarrow) symbol
> > display: by this font (glyph code)
> > uniscribe:-outline-Malgun Gothic-normal-normal-normal-
> sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
> >
> > For the ‖ (\Vert) and ※ (\textreferencemark) symbols:
> > uniscribe:-outline-MS Gothic-normal-normal-normal-
> mono-17-*-*-*-c-*-gb2312.1980-0 (#x340)
> >
> > For the symbol:
> > uniscribe:-outline-MS Gothic-normal-normal-normal-
> mono-17-*-*-*-c-*-gb2312.1980-0 (#x364)
> >
> > #### With init file ####
> >
> > (using Linux Libertine Mono as default font)
> >
> > The ‖ and ※ symbols work fine in that configuraiton.
> > "⇒" still causes the issue here too, and falls back to identically the
> same `uniscribe' line
> > uniscribe:-outline-Malgun Gothic-normal-normal-normal-
> sans-17-*-*-*-p-*-ksc5601.1987-0 (#x22D)
> >
> > The extreme lag in `package-list-packages' seems to be caused by the ▲
> symbol in the **header line**,
> > which works fine with the default font, but is substituted with
> > uniscribe:-outline-Malgun Gothic-normal-normal-normal-
> sans-16-*-*-*-p-*-gb2312.1980-0 (#x240)
> > when using `Linux Libertine Mono' or `Noto Mono'.
>
> I think the problem is that these fonts have registry that is not
> iso10646-1 (i.e. Unicode).
>
> Do you have Symbola installed?  I'm guessing you don't, and if so, can
> you please install it?  Emacs by default is configured to use that
> font for these symbols, and with the correct registry.
>
> > By any chance, do any of your test systems run Windows and have MS
> Office installed? (In my case the 2010
> > version.) It should be the primary source of Unicode fonts on my system.
>
> Yes, I do on one of my machines, and I don't experience these problems
> there.
>


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.

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.

For this file, behaviour with (setq inhibit-compacting-font-caches t) was
also somewhat inconsistent.
- Setting the variable to t always fixed the lag.
- Setting the variable back to nil keeps the buffer lag-free for a while,
but then suddenly emacs froze completely.

---------------------------

Since I don't know if attachments are archived, I also attach a the
"problematic-line.txt" as hexl/base64 dump.

00000000: 2d2a 2d20 6d6f 6465 3a20 7465 7874 3b20  -*- mode: text;
00000010: 636f 6469 6e67 3a20 7574 662d 382d 656d  coding: utf-8-em
00000020: 6163 733b 202d 2a2d 0d0a f6be a7a9 f1b5  acs; -*-........
00000030: 8485 f888 9194 94f8 8a90 a281 f88b 908e  ................
00000040: 84f8 8a98 9a9a f686 a9be f88b 8396 b5f5  ................
00000050: ac8d 8ff8 8abe a1aa f88d a4aa 9ef3 8ab8  ................
00000060: 9cf8 8eb0 9bbf f7a7 a6ae f7a7 848b f586  ................
00000070: 93ab f280 b382 f88d 958a 9ff2 a1ac 86f8  ................
00000080: 8fa0 9784 f3b5 849b f6b7 93ae f889 b4aa  ................
00000090: a2ef a39b f88a 9b96 a4f8 8dae b4b6 f88a  ................
000000a0: a9b6 bdf3 b29f a7f8 89bb 85b5 f682 a188  ................
000000b0: f88a a0a3 810d 0a                        .......

LSotIG1vZGU6IHRleHQ7IGNvZGluZzogdXRmLTgtZW1hY3M7IC0qLQ0K9r6nqfG1hIX4iJGUlPiK
kKKB+IuQjoT4ipiamvaGqb74i4OWtfWsjY/4ir6hqviNpKqe84q4nPiOsJu/96emrvenhIv1hpOr
8oCzgviNlYqf8qGshviPoJeE87WEm/a3k674ibSqou+jm/iKm5ak+I2utLb4iqm2vfOyn6f4ibuF
tfaCoYj4iqCjgQ0K

[-- Attachment #1.2: Type: text/html, Size: 7445 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: problematic-line.txt --]
[-- Type: text/plain; charset=CP932; name="problematic-line.txt", Size: 183 bytes --]

-*- mode: text; coding: utf-8-emacs; -*-
ö¾§©ñµ„…øˆ‘””øŠ¢ø‹Ž„øŠ˜ššö†©¾ø‹ƒ–µõ¬øŠ¾¡ªø¤ªžóŠ¸œøŽ°›¿÷§¦®÷§„‹õ†“«ò€³‚ø•ŠŸò¡¬†ø —„󵄛ö·“®ø‰´ª¢ï£›øŠ›–¤ø®´¶øŠ©¶½ó²Ÿ§ø‰»…µö‚¡ˆøŠ £

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

[Eli Zaretskii]

> 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.

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

[Eli Zaretskii]

> Date: Tue, 29 Nov 2016 23:17:51 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 24918@debbugs.gnu.org
> 
> I experience these slow‐downs too on my work (Windows 10) PC.
> 
> I found that I could reduce the delays by defining fallback
> fonts explicitly using:
> 
>     (set-face-attribute 'default nil :font "Droid Sans Mono")
>     (set-fontset-font nil 'unicode "DejaVu Sans" nil 'append)
>     (set-fontset-font nil 'unicode "Courier New" nil 'append)
>     (set-fontset-font nil 'unicode "Symbola" nil 'append)
> 
> but it doesn’t get rid of them completely.

Your font-spec argument in the above doesn't specify the registry.
See the definitions in fontset.el (search for "Symbola") for a better
way, which I think should avoid the delays.

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

[Klaus-Dieter Bauer]

[-- Attachment #1.1: Type: text/plain, Size: 3172 bytes --]

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: [image: 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.

[-- Attachment #1.2: Type: text/html, Size: 4676 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 215 bytes --]

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

[Eli Zaretskii]

> From: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Thu, 1 Dec 2016 11:21:36 +0100
> Cc: 24918@debbugs.gnu.org
> 
> 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)?

Maybe.  Perhaps Phillip could look into this.