* bug#24918: 25.1; Fonts can make Emacs grind to a halt @ 2016-11-10 15:53 Klaus-Dieter Bauer 2016-11-10 16:20 ` Clément Pit--Claudel 2016-11-10 17:12 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-11-10 15:53 UTC (permalink / raw) To: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-10 15:53 bug#24918: 25.1; Fonts can make Emacs grind to a halt Klaus-Dieter Bauer @ 2016-11-10 16:20 ` Clément Pit--Claudel 2016-11-10 17:12 ` Eli Zaretskii 1 sibling, 0 replies; 17+ messages in thread From: Clément Pit--Claudel @ 2016-11-10 16:20 UTC (permalink / raw) To: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-10 15:53 bug#24918: 25.1; Fonts can make Emacs grind to a halt Klaus-Dieter Bauer 2016-11-10 16:20 ` Clément Pit--Claudel @ 2016-11-10 17:12 ` Eli Zaretskii 2016-11-10 22:05 ` Klaus-Dieter Bauer 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-10 17:12 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-10 17:12 ` Eli Zaretskii @ 2016-11-10 22:05 ` Klaus-Dieter Bauer 2016-11-11 8:01 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-11-10 22:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-10 22:05 ` Klaus-Dieter Bauer @ 2016-11-11 8:01 ` Eli Zaretskii [not found] ` <CANtbJLGuWhD8jUQt_KEz82kpuknemNR8u2G71fqTav2bfrR-1Q@mail.gmail.com> 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-11 8:01 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918-done 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CANtbJLGuWhD8jUQt_KEz82kpuknemNR8u2G71fqTav2bfrR-1Q@mail.gmail.com>]
[parent not found: <83lgwc96nn.fsf@gnu.org>]
[parent not found: <CANtbJLGpF-ME-rKFfTwpU28oJDcGr2ww2vJhPUx2zxqnreOXpQ@mail.gmail.com>]
* bug#24918: 25.1; Fonts can make Emacs grind to a halt [not found] ` <CANtbJLGpF-ME-rKFfTwpU28oJDcGr2ww2vJhPUx2zxqnreOXpQ@mail.gmail.com> @ 2016-11-28 15:47 ` Eli Zaretskii 2016-11-29 10:29 ` Klaus-Dieter Bauer 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-28 15:47 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-28 15:47 ` Eli Zaretskii @ 2016-11-29 10:29 ` Klaus-Dieter Bauer 2016-11-29 14:09 ` Clément Pit--Claudel ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-11-29 10:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 10:29 ` Klaus-Dieter Bauer @ 2016-11-29 14:09 ` Clément Pit--Claudel 2016-11-29 17:47 ` Eli Zaretskii 2016-11-29 23:17 ` Alan Third 2 siblings, 0 replies; 17+ messages in thread From: Clément Pit--Claudel @ 2016-11-29 14:09 UTC (permalink / raw) To: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 10:29 ` Klaus-Dieter Bauer 2016-11-29 14:09 ` Clément Pit--Claudel @ 2016-11-29 17:47 ` Eli Zaretskii 2016-11-29 22:42 ` Klaus-Dieter Bauer 2016-11-29 23:17 ` Alan Third 2 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-29 17:47 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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). ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 17:47 ` Eli Zaretskii @ 2016-11-29 22:42 ` Klaus-Dieter Bauer 2016-11-30 3:42 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-11-29 22:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 22:42 ` Klaus-Dieter Bauer @ 2016-11-30 3:42 ` Eli Zaretskii 2016-11-30 10:01 ` Klaus-Dieter Bauer 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-30 3:42 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-30 3:42 ` Eli Zaretskii @ 2016-11-30 10:01 ` Klaus-Dieter Bauer 2016-11-30 15:00 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-11-30 10:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24918 [-- 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; -*- ö¾§©ñµ øø¢øøö©¾øµõ¬ø¾¡ªø¤ªó¸ø°¿÷§¦®÷§õ«ò³øò¡¬ø óµö·®ø´ª¢ï£ø¤ø®´¶ø©¶½ó²§ø» µö¡ø £ ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-30 10:01 ` Klaus-Dieter Bauer @ 2016-11-30 15:00 ` Eli Zaretskii 2016-12-01 10:21 ` Klaus-Dieter Bauer 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2016-11-30 15:00 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-30 15:00 ` Eli Zaretskii @ 2016-12-01 10:21 ` Klaus-Dieter Bauer 2016-12-01 17:31 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Klaus-Dieter Bauer @ 2016-12-01 10:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24918 [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-12-01 10:21 ` Klaus-Dieter Bauer @ 2016-12-01 17:31 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2016-12-01 17:31 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 10:29 ` Klaus-Dieter Bauer 2016-11-29 14:09 ` Clément Pit--Claudel 2016-11-29 17:47 ` Eli Zaretskii @ 2016-11-29 23:17 ` Alan Third 2016-11-30 15:09 ` Eli Zaretskii 2 siblings, 1 reply; 17+ messages in thread From: Alan Third @ 2016-11-29 23:17 UTC (permalink / raw) To: Klaus-Dieter Bauer; +Cc: 24918 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#24918: 25.1; Fonts can make Emacs grind to a halt 2016-11-29 23:17 ` Alan Third @ 2016-11-30 15:09 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2016-11-30 15:09 UTC (permalink / raw) To: Alan Third; +Cc: 24918, bauer.klaus.dieter > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-12-01 17:31 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-10 15:53 bug#24918: 25.1; Fonts can make Emacs grind to a halt Klaus-Dieter Bauer 2016-11-10 16:20 ` Clément Pit--Claudel 2016-11-10 17:12 ` Eli Zaretskii 2016-11-10 22:05 ` Klaus-Dieter Bauer 2016-11-11 8:01 ` Eli Zaretskii [not found] ` <CANtbJLGuWhD8jUQt_KEz82kpuknemNR8u2G71fqTav2bfrR-1Q@mail.gmail.com> [not found] ` <83lgwc96nn.fsf@gnu.org> [not found] ` <CANtbJLGpF-ME-rKFfTwpU28oJDcGr2ww2vJhPUx2zxqnreOXpQ@mail.gmail.com> 2016-11-28 15:47 ` Eli Zaretskii 2016-11-29 10:29 ` Klaus-Dieter Bauer 2016-11-29 14:09 ` Clément Pit--Claudel 2016-11-29 17:47 ` Eli Zaretskii 2016-11-29 22:42 ` Klaus-Dieter Bauer 2016-11-30 3:42 ` Eli Zaretskii 2016-11-30 10:01 ` Klaus-Dieter Bauer 2016-11-30 15:00 ` Eli Zaretskii 2016-12-01 10:21 ` Klaus-Dieter Bauer 2016-12-01 17:31 ` Eli Zaretskii 2016-11-29 23:17 ` Alan Third 2016-11-30 15:09 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).