Package: emacs;
Reported by: Will Bush <will.g.bush <at> gmail.com>
Date: Mon, 20 Apr 2020 14:56:02 UTC
Severity: normal
Tags: moreinfo
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40733 in the body.
You can then email your comments to 40733 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 14:56:02 GMT) Full text and rfc822 format available.Will Bush <will.g.bush <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Mon, 20 Apr 2020 14:56:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 06:05:58 -0500
[Message part 1 (text/plain, inline)]
Emacs freezes using 100% CPU after pasting the following into a scratch buffer: (╯°□°)╯ ︵ ┻━┻ I verified using `emacs -Q` and pasting it `C-y`. I installed Emacs 26, tried the same thing, and didn't run into an issue. Note I am assuming the above is unicode. I did not check. In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, cairo version 1.16.0) Repository revision: 80f04b5d7c817977a365a999693443c4e04e5223 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 System Description: NixOS 20.09 (Nightingale) Recent messages: Loading /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/site-lisp/site-start.el (source)...done For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP Important settings: value of $EMACSLOADPATH: /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental 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 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 Load-path shadows: /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/site-start hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/site-lisp/site-start /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-maxima hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-maxima /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-compat hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-compat /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-awk hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-awk /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-lua hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-lua /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-emacs-lisp hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-emacs-lisp /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-protocol hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-protocol /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-sql hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-sql /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-odt hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-odt /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-gnus hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-gnus /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ocaml hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ocaml /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-entities hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-entities /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-vala hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-vala /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-hledger hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-hledger /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-table hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-table /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-lint hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-lint /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-rmail hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-rmail /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-plot hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-plot /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-mouse hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-mouse /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-shen hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-shen /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-timer hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-timer /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-faces hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-faces /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-C hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-C /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-table hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-table /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-lisp hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-lisp /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-beamer hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-beamer /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-screen hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-screen /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ledger hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ledger /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-datetree hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-datetree /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-texinfo hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-texinfo /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-css hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-css /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-macro hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-macro /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-plantuml hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-plantuml /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-eshell hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-eshell /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-publish hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-publish /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-asymptote hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-asymptote /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-macs hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-macs /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-keys hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-keys /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-footnote hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-footnote /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-fortran hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-fortran /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-exp hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-exp /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-sed hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-sed /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-md hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-md /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-mhe hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-mhe /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-sass hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-sass /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-groovy hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-groovy /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-abc hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-abc /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-id hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-id /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-attach hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-attach /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-capture hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-capture /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-io hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-io /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-feed hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-feed /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-core hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-core /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-install hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-install /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-forth hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-forth /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-shell hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-shell /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-bbdb hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-bbdb /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-perl hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-perl /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-R hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-R /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-processing hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-processing /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-crypt hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-crypt /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-org hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-org /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ruby hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ruby /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-colview hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-colview /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-src hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-src /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ebnf hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ebnf /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-lilypond hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-lilypond /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-octave hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-octave /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-calc hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-calc /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-attach-git hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-attach-git /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-info hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-info /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-mscgen hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-mscgen /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-icalendar hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-icalendar /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-goto hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-goto /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-bibtex hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-bibtex /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-scheme hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-scheme /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-latex hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-latex /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-comint hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-comint /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-eval hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-eval /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-clock hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-clock /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-J hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-J /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-list hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-list /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-sqlite hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-sqlite /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-element hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-element /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-ctags hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-ctags /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-org hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-org /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-dot hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-dot /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-lob hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-lob /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-gnuplot hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-gnuplot /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-haskell hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-haskell /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-indent hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-indent /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-pcomplete hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-pcomplete /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-ascii hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-ascii /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-irc hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-irc /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-archive hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-archive /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-clojure hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-clojure /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-eww hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-eww /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-inlinetask hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-inlinetask /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-coq hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-coq /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-agenda hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-agenda /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-num hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-num /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-tempo hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-tempo /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ditaa hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ditaa /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-eshell hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-eshell /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-matlab hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-matlab /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-js hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-js /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-tangle hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-tangle /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-html hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-html /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-duration hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-duration /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-java hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-java /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-stan hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-stan /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-makefile hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-makefile /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-python hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-python /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-ref hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-ref /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-loaddefs hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-loaddefs /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-latex hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-latex /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ob-picolisp hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ob-picolisp /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ox-man hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ox-man /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-docview hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-docview /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-habit hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-habit /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/ol-w3m hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/ol-w3m /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-mobile hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-mobile /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/org-20191203/org-version hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/org/org-version /nix/store/g4spp4dhgc2cjzgfx6inh9577p67dy2i-emacs-packages-deps/share/emacs/site-lisp/elpa/let-alist-1.0.6/let-alist hides /nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0/share/emacs/28.0.50/lisp/emacs-lisp/let-alist Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils advice info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer 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 composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray 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 threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 78011 4431) (symbols 48 9045 1) (strings 32 27502 1359) (string-bytes 1 1109938) (vectors 16 13569) (vector-slots 8 183731 8028) (floats 8 24 15) (intervals 56 237 0) (buffers 992 11))
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 15:53:02 GMT) Full text and rfc822 format available.Message #8 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Robert Pluim <rpluim <at> gmail.com> To: Will Bush <will.g.bush <at> gmail.com> Cc: 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 17:52:02 +0200
>>>>> On Mon, 20 Apr 2020 06:05:58 -0500, Will Bush <will.g.bush <at> gmail.com> said:
Will> Emacs freezes using 100% CPU after pasting the following into a scratch
Will> buffer:
Will> (╯°□°)╯ ︵ ┻━┻
Does it require all of them, or is there a specific character in that
sequence that triggers it?
Any chance of running emacs using gdb so we can see where the CPU
usage is?
Will> I verified using `emacs -Q` and pasting it `C-y`. I installed Emacs 26,
Will> tried the same thing, and didn't run into an issue.
Will> Note I am assuming the above is unicode. I did not check.
Yes, it is.
Will> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.14,
Will> cairo version 1.16.0)
Iʼm confused, this is GNU/Linux, but:
Will> Configured using:
Will> 'configure
Will> --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0
Will> --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
Will> CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'
macOS defines?
If you could paste the characters one by one to see if itʼs a specific
one that causes this, and do 'C-u C-x =' on them so we know what font
is being used, that would help.
FWIW I donʼt see this on GNU/Linux. Itʼs possible itʼs font dependent.
Robert
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 16:15:01 GMT) Full text and rfc822 format available.Message #11 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Robert Pluim <rpluim <at> gmail.com> Cc: 40733 <at> debbugs.gnu.org, will.g.bush <at> gmail.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 19:13:57 +0300
> From: Robert Pluim <rpluim <at> gmail.com> > Date: Mon, 20 Apr 2020 17:52:02 +0200 > Cc: 40733 <at> debbugs.gnu.org > > FWIW I donʼt see this on GNU/Linux. And I don't see this on MS-Windows, FWIW.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 20:21:02 GMT) Full text and rfc822 format available.Message #14 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Alan Third <alan <at> idiocy.org> To: Robert Pluim <rpluim <at> gmail.com> Cc: 40733 <at> debbugs.gnu.org, Will Bush <will.g.bush <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 21:20:34 +0100
On Mon, Apr 20, 2020 at 05:52:02PM +0200, Robert Pluim wrote: > >>>>> On Mon, 20 Apr 2020 06:05:58 -0500, Will Bush <will.g.bush <at> gmail.com> said: > > Will> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, > Will> cairo version 1.16.0) > > Iʼm confused, this is GNU/Linux, but: > > Will> Configured using: > Will> 'configure > Will> --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0 > Will> --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft > Will> CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200' > > macOS defines? I’d hazard a guess that Nix uses the same build script no matter what platform it’s on and that CFLAGS setting has just been hard‐coded. -- Alan Third
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 21:50:01 GMT) Full text and rfc822 format available.Message #17 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Robert Pluim <rpluim <at> gmail.com>, 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 16:27:54 -0500
[Message part 1 (text/plain, inline)]
>
> Does it require all of them, or is there a specific character in that
> sequence that triggers it?
>
I was able to narrow it down to this character (between the back-ticks): `︵`
Gmail (webapp) is not rendering that for me even if I change the font. In
fact, I'm starting to realize I hate using gmail for writing emails because
it doesn't support code blocks either. I haven't gotten around to trying
out Emacs email clients yet, but I'm starting to wish that I had.
So I looked for a program that can turn a character into its codes and
found unum (https://www.fourmilab.ch/webtools/unum/). I inserted a
screenshot of the output (my terminal renders the character fine) because
gmail is mangling the output. I also attached a text file with the same
content as the screenshot just in case.
[image: Screenshot from 2020-04-20 14-15-29.png]
Any chance of running emacs using gdb so we can see where the CPU
> usage is?
>
Sure. I'm pretty rusty with gdb, but I'll start looking into it tonight and
get back with you. If you could give me some pointers or link me to a tips
on debugging Emacs that would help a lot.
macOS defines?
>
Looks like that comes from here:
https://github.com/NixOS/nixpkgs/blob/3bbd074217cd11b6e14abec24655091b83aacc6f/pkgs/applications/editors/emacs/default.nix#L58
Was added in this commit:
aa2160e1b62bdc6795c465e68301ec8684540b24
Author: Matthew Bauer <mjbauer95 <at> gmail.com>
AuthorDate: Mon May 28 13:33:08 2018 -0400
Commit: Matthew Bauer <mjbauer95 <at> gmail.com>
CommitDate: Mon May 28 13:35:10 2018 -0400
Parent: a87b50bc634 emacs: readd version 25
Contained: master
Follows: 18.03-beta (10672)
Precedes: 18.09-beta (9925)
emacs26: add some tweaks from jwiegley’s overlay
Interestingly, jwiegley has since removed it from his repo
https://github.com/jwiegley/nix-config in this commit:
69bb0c3ae6985f09ee2f27cea4621db21fcf0474
Author: John Wiegley <john <at> dfinity.org>
AuthorDate: Tue Oct 22 16:40:15 2019 -0700
Commit: John Wiegley <john <at> dfinity.org>
CommitDate: Tue Oct 22 16:40:15 2019 -0700
Parent: 711ed41 updates
Contained: master
updates
I guess OSX users that install Nix as a package manager can also install
Emacs using that same nix expression. I found what this flag does in the
"Targeting different macOS versions" section of the
`emacs/nextstep/INSTALL` file in the emacs repository. Kinda makes me
wonder if this should be reviewed in the nixpkgs repository.
do 'C-u C-x =' on them so we know what font
> is being used, that would help.
>
Oh cool. I didn't know about that command. So in trying to do this I
realized that Emacs did not completely lock up it was just taking a really
long time. It took a long time to display the character, for `C-u C-x =` to
finish`, and for me to finally select the text and `M-w`. Basically any
time I was interacting with that character it caused long delays.
The output below is from `emacs -Q` again in version 28 like before.
Something interesting to note is that does display the vertical left paren
after some time, but in Emacs 26, which had no lag, only displayed
whitespace.
position: 146 of 157 (92%), column: 0
character: ︵ (displayed as ︵) (codepoint 65077, #o177065,
#xfe35)
charset: unicode (Unicode (ISO10646))
code point in charset: 0xFE35
script: han
syntax: (︶ which means: open, matches ︶
category: .:Base, c:Chinese
to input: type "C-x 8 RET fe35" or "C-x 8 RET PRESENTATION
FORM FOR VERTICAL LEFT PARENTHESIS"
buffer code: #xEF #xB8 #xB5
file code: #xEF #xB8 #xB5 (encoded by coding system utf-8-unix)
display: by this font (glyph code)
ftcrhb:-GNU-Unifont-normal-normal-normal-Sans-Serif-16-*-*-*-c-80-iso10646-1
(#xDD36)
Character code properties: customize what to show
name: PRESENTATION FORM FOR VERTICAL LEFT PARENTHESIS
old-name: GLYPH FOR VERTICAL OPENING PARENTHESIS
general-category: Ps (Punctuation, Open)
decomposition: (vertical 40) (vertical '(')
There are text properties here:
fontified nil
rear-nonsticky t
[Message part 2 (text/html, inline)]
[Screenshot from 2020-04-20 14-15-29.png (image/png, inline)]
[unum-output.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 20 Apr 2020 22:49:02 GMT) Full text and rfc822 format available.Message #20 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: "Basil L. Contovounesios" <contovob <at> tcd.ie> To: Will Bush <will.g.bush <at> gmail.com> Cc: 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Apr 2020 23:48:48 +0100
Will Bush <will.g.bush <at> gmail.com> writes:
> Configured using:
> 'configure
> --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0
> --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
^^^^^^^^^^
I know next to nothing about fonts, and I'm sure others will correct me,
but etc/NEWS has the following to say:
** 'configure' now warns about building with libXft support.
libXft is unmaintained, and causes a number of problems with modern
fonts including but not limited to crashes; support for it may be
removed in a future version of Emacs. Please consider using
Cairo + HarfBuzz instead.
I don't know if it's related (and the 'C-u C-x =' output in your other
message shows the ftcrhb backend in use), but perhaps you can try
building --without-xft to see if it makes any difference.
--
Basil
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Tue, 21 Apr 2020 10:02:01 GMT) Full text and rfc822 format available.Message #23 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Robert Pluim <rpluim <at> gmail.com> To: "Basil L. Contovounesios" <contovob <at> tcd.ie> Cc: 40733 <at> debbugs.gnu.org, Will Bush <will.g.bush <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 21 Apr 2020 12:01:48 +0200
>>>>> On Mon, 20 Apr 2020 23:48:48 +0100, "Basil L. Contovounesios" <contovob <at> tcd.ie> said:
Basil> Will Bush <will.g.bush <at> gmail.com> writes:
>> Configured using:
>> 'configure
>> --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0
>> --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
Basil> ^^^^^^^^^^
Basil> I know next to nothing about fonts, and I'm sure others will correct me,
Basil> but etc/NEWS has the following to say:
Basil> ** 'configure' now warns about building with libXft support.
Basil> libXft is unmaintained, and causes a number of problems with modern
Basil> fonts including but not limited to crashes; support for it may be
Basil> removed in a future version of Emacs. Please consider using
Basil> Cairo + HarfBuzz instead.
Basil> I don't know if it's related (and the 'C-u C-x =' output in your other
Basil> message shows the ftcrhb backend in use), but perhaps you can try
Basil> building --without-xft to see if it makes any difference.
If it does thatʼs a bug, since we implicitly do '--with-cairo' now.
Robert
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Tue, 21 Apr 2020 12:21:01 GMT) Full text and rfc822 format available.Message #26 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Robert Pluim <rpluim <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 21 Apr 2020 07:19:56 -0500
[Message part 1 (text/plain, inline)]
Ok I've made some progress on this issue. I was playing around with my fonts: https://github.com/willbush/system/blob/085e4c547f0bd84729f12f82b920d867d05e1591/nixos/fonts.nix#L7 I was curious how many fonts I would have (using `fc-list | wc -l`) if I removed them all from that list. After removing them all, I checked my email in Gmail using Firefox and noticed the `︵` was rendering properly. Then I tried pasting it into Emacs and lo and behold no lag issue! So I did a binary search through my font list commenting / uncommenting them and applying the changes with `sudo nixos rebuild switch` (as one does in NixOS), and found google-fonts is causing the issue. I verified it several times. When I remove google-fonts, Firefox renders the character fine and Emacs yanks it without issue. When I add google-fonts back Firefox doesn't render the character and Emacs yanking it lags like crazy. The google-fonts Nix expression is here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/data/fonts/google-fonts/default.nix I tried Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.17) (A version that just happens to be in nixpkgs) again to see what it would do when yanking that character with and without google-fonts installed. With google-fonts installed it doesn't have latency issues, but it inserts an empty whitespace looking character (wider than a normal space). Without google-fonts installed, it renders the character fine with no latency. So I suspect even if there is an issue with google-fonts, there's still a regression in Emacs since 26.3. I'll try newer versions of Emacs later to try to narrow the version gap between 26.3 and 28.0.50. Perhaps someone can try to reproduce the issue by installing google-fonts (note the git rev used in default.nix above is f113126dc4b9b1473d9354a86129c9d7b837aa1a for https://github.com/google/fonts). On Tue, Apr 21, 2020 at 5:01 AM Robert Pluim <rpluim <at> gmail.com> wrote: > >>>>> On Mon, 20 Apr 2020 23:48:48 +0100, "Basil L. Contovounesios" < > contovob <at> tcd.ie> said: > > Basil> Will Bush <will.g.bush <at> gmail.com> writes: > >> Configured using: > >> 'configure > >> > --prefix=/nix/store/2142cl219v49czkkrrddh3jy3415nax0-emacs-git-20200420.0 > >> --disable-build-details --with-modules --with-x-toolkit=gtk3 > --with-xft > Basil> > ^^^^^^^^^^ > > Basil> I know next to nothing about fonts, and I'm sure others will > correct me, > Basil> but etc/NEWS has the following to say: > > Basil> ** 'configure' now warns about building with libXft support. > Basil> libXft is unmaintained, and causes a number of problems with > modern > Basil> fonts including but not limited to crashes; support for it > may be > Basil> removed in a future version of Emacs. Please consider using > Basil> Cairo + HarfBuzz instead. > > Basil> I don't know if it's related (and the 'C-u C-x =' output in > your other > Basil> message shows the ftcrhb backend in use), but perhaps you can > try > Basil> building --without-xft to see if it makes any difference. > > If it does thatʼs a bug, since we implicitly do '--with-cairo' now. > > Robert >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Tue, 21 Apr 2020 13:20:01 GMT) Full text and rfc822 format available.Message #29 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Robert Pluim <rpluim <at> gmail.com> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 21 Apr 2020 15:19:08 +0200
>>>>> On Tue, 21 Apr 2020 07:19:56 -0500, Will Bush <will.g.bush <at> gmail.com> said:
Will> I verified it several times. When I remove google-fonts, Firefox renders the
Will> character fine and Emacs yanks it without issue. When I add google-fonts
Will> back
Will> Firefox doesn't render the character and Emacs yanking it lags like crazy.
Thatʼs interesting to know. Which font specifically does emacs end up
using for that character? Emacs ends up using 'Noto Sans CJK KR' for
me here. BTW, if you want to ignore that font, you can set
'face-ignored-fonts' to match it, and you won't have to uninstall it.
Will> The google-fonts Nix expression is here:
Will> https://github.com/NixOS/nixpkgs/blob/master/pkgs/data/fonts/google-fonts/default.nix
Will> I tried Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.17) (A
Will> version that just happens to be in nixpkgs) again to see what it would do
Will> when
Will> yanking that character with and without google-fonts installed.
Will> With google-fonts installed it doesn't have latency issues, but it inserts
Will> an
Will> empty whitespace looking character (wider than a normal space). Without
Will> google-fonts installed, it renders the character fine with no latency.
Will> So I suspect even if there is an issue with google-fonts, there's still a
Will> regression in Emacs since 26.3. I'll try newer versions of Emacs later to
Will> try to
Will> narrow the version gap between 26.3 and 28.0.50.
I donʼt think thereʼs much point in that: emacs-26 uses Xft for font
handling, emacs-27 uses Cairo+Harfbuzz[1]; theyʼre fundamentally doing
very different things, so I donʼt think this is caused by a single
identifiable change.
Robert
Footnotes:
[1] Although you can still build it with Xft if you want, but I
wouldnʼt recommend that, since it will crash once you start
processing Emojis and other 'interesting' Unicode characters.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Tue, 21 Apr 2020 14:30:02 GMT) Full text and rfc822 format available.Message #32 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: contovob <at> tcd.ie, rpluim <at> gmail.com, 40733 <at> debbugs.gnu.org Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 21 Apr 2020 17:29:14 +0300
> From: Will Bush <will.g.bush <at> gmail.com> > Date: Tue, 21 Apr 2020 07:19:56 -0500 > Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org > > I tried Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.17) (A > version that just happens to be in nixpkgs) again to see what it would do when > yanking that character with and without google-fonts installed. > > With google-fonts installed it doesn't have latency issues, but it inserts an > empty whitespace looking character (wider than a normal space). Without > google-fonts installed, it renders the character fine with no latency. > > So I suspect even if there is an issue with google-fonts, there's still a > regression in Emacs since 26.3. I'm not sure I understand: you are saying that slow, but correct display is _worse_ than displaying a white space instead of the correct glyph, i.e. producing incorrect display? To me, it sounds like Emacs 27+ actually _improves_ things in this case.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Tue, 21 Apr 2020 19:36:02 GMT) Full text and rfc822 format available.Message #35 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: James Cloos <cloos <at> jhcloos.com> To: Robert Pluim <rpluim <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Will Bush <will.g.bush <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 21 Apr 2020 15:35:23 -0400
>>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes: RP> Footnotes: RP> [1] Although you can still build it with Xft if you want, but I RP> wouldnʼt recommend that, since it will crash once you start RP> processing Emojis and other 'interesting' Unicode characters. note that master will also crash when using cr+hb on some code points. such as some private use characters. less often, but stll sometimes. -JimC -- James Cloos <cloos <at> jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 22 Apr 2020 07:36:01 GMT) Full text and rfc822 format available.Message #38 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Robert Pluim <rpluim <at> gmail.com> To: James Cloos <cloos <at> jhcloos.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Will Bush <will.g.bush <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 22 Apr 2020 09:35:42 +0200
>>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos <at> jhcloos.com> said:
>>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
RP> Footnotes:
RP> [1] Although you can still build it with Xft if you want, but I
RP> wouldnʼt recommend that, since it will crash once you start
RP> processing Emojis and other 'interesting' Unicode characters.
James> note that master will also crash when using cr+hb on some code points.
James> such as some private use characters.
Examples? Eli fixed one such case with Bug#39892, but if there are
more we should fix them (please open a separate bug report for that).
Robert
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sat, 25 Apr 2020 10:35:02 GMT) Full text and rfc822 format available.Message #41 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Robert Pluim <rpluim <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Sat, 25 Apr 2020 05:34:23 -0500
[Message part 1 (text/plain, inline)]
Robert> Which font specifically does emacs end up using for that character? Robert> Emacs ends up using 'Noto Sans CJK KR' for me here. When google fonts is removed? This is what `C-u C-x =` says: ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1 (#xDD38ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1 (#xDD38) Note on the above: For the hell of it, I tried installing `noto-fonts` font pack from nixpkgs and it didn't make a difference. Then again, `fc-list --verbose | rg "Noto Sans CJK" -i` produced no results so that specific font probably isn't in that font pack. When google fonts are installed: ftcrhb:-GNU-Unifont-normal-normal-normal-Sans-Serif-16-*-*-*-c-80-iso10646-1 (#xDD36) Robert> BTW, if you want to ignore that font, you can set Robert> 'face-ignored-fonts' to match it, and you won't have to uninstall it. Thanks, I didn't know that! Maybe I can use that to narrow down to the specific font that's causing problems because adding `google-fonts` adds 2905 fonts for me, and many I would like to have. Robert> I donʼt think thereʼs much point in that: emacs-26 uses Xft for font Robert> handling, emacs-27 uses Cairo+Harfbuzz[1]; theyʼre fundamentally doing Robert> very different things, so I donʼt think this is caused by a single Robert> identifiable change. I'm not trying to prove you wrong or anything. It's just easy for me to try different versions because I'm using (https://github.com/nix-community/emacs-overlay). However, I tried Emacs 27.0.50 and it's behaving exactly the same as Emacs 26. I glanced at the `report-emacs-bug` output and the build inputs look the same. I can include it if desired. λ ~/ time emacs -Q --eval '(message "hi")' -kill emacs -Q --eval '(message "hi")' -kill 0.18s user 0.02s system 67% cpu 0.303 total λ ~/ time emacs -Q --eval '(message "︵")' -kill emacs -Q --eval '(message "︵")' -kill 0.44s user 0.03s system 95% cpu 0.494 total λ ~/ emacs --version GNU Emacs 27.0.50 Robert> ...we implicitly do '--with-cairo' now. Is that since 27.0.50? Were either Cairo+Harfbuzz libraries updated since 27.0.50 (perhaps a regression in those libraries)? I'll follow up with an update later after testing more versions. Robert> Although you can still build it with Xft if you want, but I Robert> wouldnʼt recommend that, since it will crash once you start Robert> processing Emojis and other 'interesting' Unicode characters. Just to verity I understand. Building with Xft is what `--with-xft` is doing in the following from my initial email? Configured using: 'configure --prefix=/nix/store/5v0fp6vikajaqc2v0ppkm51hfc054mnm-emacs-git-20190910.0 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200' Eli> I'm not sure I understand: you are saying that slow, but correct Eli> display is _worse_ than displaying a white space instead of the Eli> correct glyph, i.e. producing incorrect display? To me, it sounds Eli> like Emacs 27+ actually _improves_ things in this case. Let me quantify the performance because I've been ambiguous about it so far: λ ~/ time emacs -Q --eval '(message "hi")' -kill emacs -Q --eval '(message "hi")' -kill 0.19s user 0.02s system 55% cpu 0.371 total λ ~/ time emacs -Q --eval '(message "︵")' -kill emacs -Q --eval '(message "︵")' -kill 81.64s user 0.03s system 99% cpu 1:21.91 total It takes ~81 seconds to do something while locking up the UI. That's personally beyond my threshold for killing the process. On Wed, Apr 22, 2020 at 2:35 AM Robert Pluim <rpluim <at> gmail.com> wrote: > >>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos <at> jhcloos.com> > said: > > >>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes: > RP> Footnotes: > RP> [1] Although you can still build it with Xft if you want, but I > RP> wouldnʼt recommend that, since it will crash once you start > RP> processing Emojis and other 'interesting' Unicode characters. > > James> note that master will also crash when using cr+hb on some code > points. > > James> such as some private use characters. > > Examples? Eli fixed one such case with Bug#39892, but if there are > more we should fix them (please open a separate bug report for that). > > Robert >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sat, 25 Apr 2020 13:35:01 GMT) Full text and rfc822 format available.Message #44 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: James Cloos <cloos <at> jhcloos.com>, "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com> Subject: Fwd: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Sat, 25 Apr 2020 08:34:05 -0500
[Message part 1 (text/plain, inline)]
I forgot to CC everyone.
---------- Forwarded message ---------
From: Will Bush <will.g.bush <at> gmail.com>
Date: Sat, Apr 25, 2020 at 8:30 AM
Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode
characters
To: Robert Pluim <rpluim <at> gmail.com>
Robert> ...we implicitly do '--with-cairo' now.
Will> Is that since 27.0.50?
Think I just answered my own question the hard way.
I was able to narrow the performance issue to starting after rev
`6100f9a19e9d8d8e688ad8bbec2233bd6782cbde` and before or at
`a75047634697acbc37a9ecd58cc5e7ea9d89d91f` in the master branch in Emacs
repository.
Which corresponds to these commits:
06caa3b7e5 | * | Refactor Tramp async process code
88efc736f5 | * | Default cairo to enabled
4fc0bc9678 | * | Update from gnulib
0abda558bc | * | Port configure.ac to future Gnulib
6100f9a19e | * | * src/pdumper.c (dump_vectorlike): Unbreak build after
724af7671590c
Lol "Default cairo to enabled" really stands out there. It's probably safe
to
assume that's what it is.
Following goes into extraneous detail showing how I verified it's between
those
two revisions:
λ ~/system/nixos/ emacs/revamp* niv update emacs-overlay -a
rev=0feda8b31b52f3ea008555dfe79dba3989d3e585
Update emacs-overlay
Reading sources file
Done: Update emacs-overlay
λ ~/system/nixos/ emacs/revamp* home-manager switch
... home manager spam goes here
λ ~/system/nixos/ emacs/revamp* time emacs -Q --eval '(message "︵")' -kill
emacs -Q --eval '(message "︵")' -kill 0.42s user 0.02s system 64% cpu
0.690 total
λ ~/system/nixos/ emacs/revamp* time emacs -Q --eval '(message "︵")' -kill
emacs -Q --eval '(message "︵")' -kill 0.43s user 0.02s system 94% cpu
0.472 total
λ ~/system/nixos/ emacs/revamp* niv update emacs-overlay -a
rev=a75047634697acbc37a9ecd58cc5e7ea9d89d91f
Update emacs-overlay
Reading sources file
Done: Update emacs-overlay
λ ~/system/nixos/ emacs/revamp* home-manager switch
... more home manager spam
λ ~/system/nixos/ emacs/revamp* time emacs -Q --eval '(message "︵")' -kill
emacs -Q --eval '(message "︵")' -kill 80.73s user 0.02s system 99% cpu
1:20.97 total
λ ~/system/nixos/ emacs/revamp*
The `niv update emacs-overlay -a
rev=a75047634697acbc37a9ecd58cc5e7ea9d89d91f`
command is using a tool called niv to update emacs-overlay to a pinned
version.
The rev in the diff below is for the Emacs repository.
*# perf issue:*
a75047634697acbc37a9ecd58cc5e7ea9d89d91f
Author: emacs-overlay <emacs-overlay <at> nix-community>
AuthorDate: Tue Jan 14 12:10:25 2020 +0000
Commit: emacs-overlay <emacs-overlay <at> nix-community>
CommitDate: Tue Jan 14 12:10:25 2020 +0000
Parent: 9351772 Updated repos/melpa
Contained: master
Updated repos/emacs
modified repos/emacs/emacs.json
@@ -1 +1 @@
-{"rev": "4fc0bc96787252b1b3e14a7f747ef556273b5979", "sha256":
"0syw4xcbps6i62fa7l88zyvyc3kiggx2kpa2n41p8y2pl01vdqqs", "version":
"20200114.0"}
+{"rev": "06caa3b7e5e9fe91b6918f8567adbd5501d6dbdd", "sha256":
"0kzk30660xky0zj7v5sr9a49pnnz609jda4s8x86pjk91x1wrv2i", "version":
"20200114.0"}
*# no perf issue:*
0feda8b31b52f3ea008555dfe79dba3989d3e585
Author: emacs-overlay <emacs-overlay <at> nix-community>
AuthorDate: Mon Jan 13 00:10:30 2020 +0000
Commit: emacs-overlay <emacs-overlay <at> nix-community>
CommitDate: Mon Jan 13 00:10:30 2020 +0000
Parent: e38dc3b Updated repos/melpa
Contained: master
Updated repos/emacs
modified repos/emacs/emacs.json
@@ -1 +1 @@
-{"rev": "41d9d51cf5ac5b76c09802388e1691cf489d9d9d", "sha256":
"1vy1fcw2m7lbw8wcwmp04zwkqra835vdbxbgnms3wgrwviqm14zd", "version":
"20200111.0"}
+{"rev": "6100f9a19e9d8d8e688ad8bbec2233bd6782cbde", "sha256":
"01fvxplljwnz11sizlfpl219dvrg7yf790zmr69wvkn6wlgxif76", "version":
"20200112.0"}
On Sat, Apr 25, 2020 at 5:34 AM Will Bush <will.g.bush <at> gmail.com> wrote:
> Robert> Which font specifically does emacs end up using for that character?
> Robert> Emacs ends up using 'Noto Sans CJK KR' for me here.
>
> When google fonts is removed?
>
> This is what `C-u C-x =` says:
>
> ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1
> (#xDD38ftcrhb:-PfEd-Unifont-normal-normal-normal-*-15-*-*-*-d-0-iso10646-1
> (#xDD38)
>
> Note on the above: For the hell of it, I tried installing `noto-fonts`
> font pack
> from nixpkgs and it didn't make a difference. Then again, `fc-list
> --verbose |
> rg "Noto Sans CJK" -i` produced no results so that specific font probably
> isn't
> in that font pack.
>
> When google fonts are installed:
>
> ftcrhb:-GNU-Unifont-normal-normal-normal-Sans-Serif-16-*-*-*-c-80-iso10646-1
> (#xDD36)
>
> Robert> BTW, if you want to ignore that font, you can set
> Robert> 'face-ignored-fonts' to match it, and you won't have to uninstall
> it.
>
> Thanks, I didn't know that! Maybe I can use that to narrow down to the
> specific
> font that's causing problems because adding `google-fonts` adds 2905 fonts
> for
> me, and many I would like to have.
>
> Robert> I donʼt think thereʼs much point in that: emacs-26 uses Xft for
> font
> Robert> handling, emacs-27 uses Cairo+Harfbuzz[1]; theyʼre fundamentally
> doing
> Robert> very different things, so I donʼt think this is caused by a single
> Robert> identifiable change.
>
> I'm not trying to prove you wrong or anything. It's just easy for me to try
> different versions because I'm using
> (https://github.com/nix-community/emacs-overlay). However, I tried Emacs
> 27.0.50
> and it's behaving exactly the same as Emacs 26. I glanced at the
> `report-emacs-bug` output and the build inputs look the same. I can
> include it
> if desired.
>
> λ ~/ time emacs -Q --eval '(message "hi")' -kill
> emacs -Q --eval '(message "hi")' -kill 0.18s user 0.02s system 67% cpu
> 0.303 total
> λ ~/ time emacs -Q --eval '(message "︵")' -kill
> emacs -Q --eval '(message "︵")' -kill 0.44s user 0.03s system 95% cpu
> 0.494 total
> λ ~/ emacs --version
> GNU Emacs 27.0.50
>
> Robert> ...we implicitly do '--with-cairo' now.
>
> Is that since 27.0.50?
>
> Were either Cairo+Harfbuzz libraries updated since 27.0.50 (perhaps a
> regression
> in those libraries)? I'll follow up with an update later after testing
> more versions.
>
> Robert> Although you can still build it with Xft if you want, but I
> Robert> wouldnʼt recommend that, since it will crash once you start
> Robert> processing Emojis and other 'interesting' Unicode characters.
>
> Just to verity I understand. Building with Xft is what `--with-xft` is
> doing in
> the following from my initial email?
>
> Configured using:
> 'configure
> --prefix=/nix/store/5v0fp6vikajaqc2v0ppkm51hfc054mnm-emacs-git-20190910.0
> --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
> CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'
>
> Eli> I'm not sure I understand: you are saying that slow, but correct
> Eli> display is _worse_ than displaying a white space instead of the
> Eli> correct glyph, i.e. producing incorrect display? To me, it sounds
> Eli> like Emacs 27+ actually _improves_ things in this case.
>
> Let me quantify the performance because I've been ambiguous about it so
> far:
>
> λ ~/ time emacs -Q --eval '(message "hi")' -kill
> emacs -Q --eval '(message "hi")' -kill 0.19s user 0.02s system 55% cpu
> 0.371 total
> λ ~/ time emacs -Q --eval '(message "︵")' -kill
> emacs -Q --eval '(message "︵")' -kill 81.64s user 0.03s system 99% cpu
> 1:21.91 total
>
> It takes ~81 seconds to do something while locking up the UI. That's
> personally
> beyond my threshold for killing the process.
>
>
> On Wed, Apr 22, 2020 at 2:35 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
>> >>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos <at> jhcloos.com>
>> said:
>>
>> >>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
>> RP> Footnotes:
>> RP> [1] Although you can still build it with Xft if you want, but I
>> RP> wouldnʼt recommend that, since it will crash once you start
>> RP> processing Emojis and other 'interesting' Unicode characters.
>>
>> James> note that master will also crash when using cr+hb on some code
>> points.
>>
>> James> such as some private use characters.
>>
>> Examples? Eli fixed one such case with Bug#39892, but if there are
>> more we should fix them (please open a separate bug report for that).
>>
>> Robert
>>
>
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sat, 25 Apr 2020 13:52:02 GMT) Full text and rfc822 format available.Message #47 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: contovob <at> tcd.ie, rpluim <at> gmail.com, 40733 <at> debbugs.gnu.org, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Sat, 25 Apr 2020 16:50:59 +0300
> From: Will Bush <will.g.bush <at> gmail.com> > Date: Sat, 25 Apr 2020 05:34:23 -0500 > Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, > James Cloos <cloos <at> jhcloos.com> > > Eli> I'm not sure I understand: you are saying that slow, but correct > Eli> display is _worse_ than displaying a white space instead of the > Eli> correct glyph, i.e. producing incorrect display? To me, it sounds > Eli> like Emacs 27+ actually _improves_ things in this case. > > Let me quantify the performance because I've been ambiguous about it so far: > > λ ~/ time emacs -Q --eval '(message "hi")' -kill > emacs -Q --eval '(message "hi")' -kill 0.19s user 0.02s system 55% cpu 0.371 total > λ ~/ time emacs -Q --eval '(message "︵")' -kill > emacs -Q --eval '(message "︵")' -kill 81.64s user 0.03s system 99% cpu 1:21.91 total > > It takes ~81 seconds to do something while locking up the UI. That's personally > beyond my threshold for killing the process. It would be good to know what happens in Emacs during those 88 seconds. Please try using "M-x profiler" to find out.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 29 Apr 2020 12:01:02 GMT) Full text and rfc822 format available.Message #50 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Robert Pluim <rpluim <at> gmail.com>, 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 29 Apr 2020 06:59:42 -0500
[Message part 1 (text/plain, inline)]
>
> It would be good to know what happens in Emacs during those 88
> seconds. Please try using "M-x profiler" to find out.
>
Here's what I get with `M-x profiler-start`, using the default cpu sampling,
`C-y` the character into a scratch buffer, wait for the character to show
up,
`M-x profiler-stop`, and start `M-x profiler-report`:
- command-execute 34 68%
- call-interactively 34 68%
- byte-code 27 54%
- read-extended-command 27 54%
- completing-read 27 54%
- completing-read-default 27 54%
- read-from-minibuffer 20 40%
- redisplay_internal (C function) 3 6%
- tool-bar-make-keymap 1 2%
- tool-bar-make-keymap-1 1 2%
- mapcar 1 2%
- #<compiled 0x3e964ab88a0e574> 1 2%
- eval 1 2%
- find-image 1 2%
image-search-load-path 1 2%
- mode-line-default-help-echo 1 2%
window-at-side-p 1 2%
- funcall 1 2%
- #<compiled -0x1f995e3cc2b2ecb1> 1 2%
- gui-backend-selection-exists-p 1 2%
- apply 1 2%
#<compiled 0x6140be5b29e66b5> 1 2%
- command-execute 1 2%
- call-interactively 1 2%
- funcall-interactively 1 2%
self-insert-command 1 2%
- funcall-interactively 7 14%
- execute-extended-command 7 14%
- sit-for 6 12%
- redisplay 5 10%
- redisplay_internal (C function) 1 2%
- tool-bar-make-keymap 1 2%
- tool-bar-make-keymap-1 1 2%
- mapcar 1 2%
- #<compiled 0x3e964ab88a0e574> 1 2%
- eval 1 2%
- find-image 1 2%
image-search-load-path 1 2%
- command-execute 1 2%
- call-interactively 1 2%
- funcall-interactively 1 2%
profiler-stop 1 2%
- ... 15 30%
Automatic GC 11 22%
- minibuffer-complete 4 8%
- completion-in-region 4 8%
- completion--in-region 4 8%
- #<compiled -0x1e2ae9bfb330a9ab> 4 8%
- apply 4 8%
- #<compiled -0x1803b12e396f20ff> 4 8%
- completion--in-region-1 4 8%
- completion--do-completion 4 8%
- completion-try-completion 2 4%
- completion--nth-completion 2 4%
- completion--some 2 4%
- #<compiled 0x19362eb0698d1781> 2 4%
- completion-basic-try-completion 2 4%
- try-completion 2 4%
- #<compiled 0x8eea649a66594a4> 2 4%
complete-with-action 2 4%
- minibuffer-completion-help 2 4%
- completion-all-completions 1 2%
- completion--nth-completion 1 2%
- completion--some 1 2%
- #<compiled 0x19362eb0508d1781> 1 2%
- completion-basic-all-completions 1 2%
- completion-pcm--all-completions 1 2%
- all-completions 1 2%
- #<compiled 0x8eea649a66594a4> 1 2%
complete-with-action 1 2%
- temp-buffer-window-show 1 2%
- display-buffer 1 2%
- display-buffer-at-bottom 1 2%
- window--display-buffer 1 2%
- #<compiled -0x142698e7aac52b3a> 1 2%
- display-completion-list 1 2%
- completion--insert-strings 1 2%
- mapcar 1 2%
#<compiled -0x6d88f6ac78df9> 1 2%
- timer-event-handler 1 2%
- apply 1 2%
#<compiled 0x2393a4a91a526d> 1 2%
On Sat, Apr 25, 2020 at 8:51 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Will Bush <will.g.bush <at> gmail.com>
> > Date: Sat, 25 Apr 2020 05:34:23 -0500
> > Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org,
> > James Cloos <cloos <at> jhcloos.com>
> >
> > Eli> I'm not sure I understand: you are saying that slow, but correct
> > Eli> display is _worse_ than displaying a white space instead of the
> > Eli> correct glyph, i.e. producing incorrect display? To me, it sounds
> > Eli> like Emacs 27+ actually _improves_ things in this case.
> >
> > Let me quantify the performance because I've been ambiguous about it so
> far:
> >
> > λ ~/ time emacs -Q --eval '(message "hi")' -kill
> > emacs -Q --eval '(message "hi")' -kill 0.19s user 0.02s system 55% cpu
> 0.371 total
> > λ ~/ time emacs -Q --eval '(message "︵")' -kill
> > emacs -Q --eval '(message "︵")' -kill 81.64s user 0.03s system 99% cpu
> 1:21.91 total
> >
> > It takes ~81 seconds to do something while locking up the UI. That's
> personally
> > beyond my threshold for killing the process.
>
> It would be good to know what happens in Emacs during those 88
> seconds. Please try using "M-x profiler" to find out.
>
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 29 Apr 2020 12:17:01 GMT) Full text and rfc822 format available.Message #53 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: contovob <at> tcd.ie, rpluim <at> gmail.com, 40733 <at> debbugs.gnu.org, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 29 Apr 2020 15:16:12 +0300
> From: Will Bush <will.g.bush <at> gmail.com> > Date: Wed, 29 Apr 2020 06:59:42 -0500 > Cc: Robert Pluim <rpluim <at> gmail.com>, "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, > James Cloos <cloos <at> jhcloos.com> > > It would be good to know what happens in Emacs during those 88 > seconds. Please try using "M-x profiler" to find out. > > Here's what I get with `M-x profiler-start`, using the default cpu sampling, > `C-y` the character into a scratch buffer, wait for the character to show up, > `M-x profiler-stop`, and start `M-x profiler-report`: You shouldn't invoke profiler-stop, it affects the profile. Just profiler-start, do what you want to profile, then profiler-report. From what you posted, it looks like GC is a major player, but it's hard to be sure (and 88 sec is a lot of time for a GC). Please show the profile collected as suggested above. Thanks.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 29 Apr 2020 12:43:02 GMT) Full text and rfc822 format available.Message #56 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Robert Pluim <rpluim <at> gmail.com>, 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 29 Apr 2020 07:42:20 -0500
[Message part 1 (text/plain, inline)]
Did you see my other message that I forwarded where I forgot to CC
everyone? I
was able to switch between a bunch of revisions of the master branch to see
where the performance issue started, and it appears to have started with
commit
(88efc736f5 Default cairo to enabled). I was hoping that would narrow it
down.
Maybe an upstream bug needs to be reported.
Here is the profiler report without stopping:
- command-execute 29 37%
- call-interactively 29 37%
- byte-code 21 27%
- read-extended-command 21 27%
- completing-read 21 27%
- completing-read-default 21 27%
- read-from-minibuffer 15 19%
- redisplay_internal (C function) 1 1%
- tool-bar-make-keymap 1 1%
- tool-bar-make-keymap-1 1 1%
- mapcar 1 1%
- #<compiled -0xdd262bffb4f5e94> 1 1%
- eval 1 1%
- find-image 1 1%
image-search-load-path 1 1%
- funcall-interactively 8 10%
- execute-extended-command 7 9%
- sit-for 6 7%
redisplay 5 6%
- command-execute 1 1%
- call-interactively 1 1%
- funcall-interactively 1 1%
profiler-report 1 1%
- yank 1 1%
- current-kill 1 1%
- gui-selection-value 1 1%
- gui--selection-value-internal 1 1%
- gui-get-selection 1 1%
- gui-backend-get-selection 1 1%
- cl--generic-cache-miss 1 1%
- cl--generic-make-next-function 1 1%
- cl--generic-build-combined-method 1 1%
- cl-generic-combine-methods 1 1%
cl--generic-standard-method-combination 1
1%
- ... 25 32%
Automatic GC 19 24%
- minibuffer-complete 6 7%
- completion-in-region 6 7%
- completion--in-region 6 7%
- #<compiled -0x1e2e37146f1969ab> 6 7%
- apply 6 7%
- #<compiled 0x1148c3ec647cd895> 6 7%
- completion--in-region-1 6 7%
- completion--do-completion 6 7%
- completion-try-completion 4 5%
- completion--nth-completion 4 5%
- completion--some 4 5%
- #<compiled 0x193a0f848bfa1981> 4 5%
- completion-basic-try-completion 4 5%
- try-completion 4 5%
- #<compiled -0x1b219ba5d00e6b5b> 4 5%
complete-with-action 4 5%
- minibuffer-completion-help 2 2%
- completion-all-completions 1 1%
- completion--nth-completion 1 1%
- completion--some 1 1%
- #<compiled 0x193a0460dbba5781> 1 1%
- completion-basic-all-completions 1 1%
- completion-pcm--all-completions 1 1%
- all-completions 1 1%
- #<compiled -0x1b219ba5d00e6b5b> 1 1%
complete-with-action 1 1%
- temp-buffer-window-show 1 1%
- display-buffer 1 1%
- display-buffer-at-bottom 1 1%
- walk-window-tree 1 1%
- walk-window-tree-1 1 1%
- #<compiled -0xe1696a80dea244c> 1 1%
window-in-direction 1 1%
- mouse--click-1-maybe-follows-link 23 29%
- time-since 11 14%
byte-code 11 14%
Ran it again with this set first (didn't seem any faster, but I didn't
measure how long):
(setq gc-cons-threshold most-positive-fixnum)
- command-execute 63 80%
- call-interactively 63 80%
- funcall-interactively 49 62%
- execute-extended-command 48 61%
- execute-extended-command--shorter 37 47%
- completion-try-completion 37 47%
- completion--nth-completion 37 47%
- completion--some 37 47%
- #<compiled 0x8040425f3c02ca8> 37 47%
- completion-pcm-try-completion 29 37%
- completion-pcm--find-all-completions 28 35%
completion-pcm--all-completions 28 35%
completion-pcm--merge-try 1 1%
completion-basic-try-completion 8 10%
- sit-for 10 12%
redisplay 5 6%
- command-execute 1 1%
- call-interactively 1 1%
- funcall-interactively 1 1%
profiler-report 1 1%
- yank 1 1%
- insert-for-yank 1 1%
insert-for-yank-1 1 1%
- byte-code 14 17%
- read-extended-command 14 17%
- completing-read 14 17%
- completing-read-default 14 17%
read-from-minibuffer 6 7%
- ... 13 16%
Automatic GC 12 15%
- minibuffer-complete 1 1%
- completion-in-region 1 1%
- completion--in-region 1 1%
- #<compiled -0x1e2d5057a11b69ab> 1 1%
- apply 1 1%
- #<compiled -0x29426ad1f232709> 1 1%
- completion--in-region-1 1 1%
- completion--do-completion 1 1%
- completion-try-completion 1 1%
- completion--nth-completion 1 1%
- completion--some 1 1%
- #<compiled -0x1aaa3a826ece83ff> 1 1%
- completion-basic-try-completion 1 1%
- try-completion 1 1%
- #<compiled -0x4b2d19c512e6b51> 1 1%
complete-with-action 1 1%
- redisplay_internal (C function) 1 1%
- tool-bar-make-keymap 1 1%
- tool-bar-make-keymap-1 1 1%
- mapcar 1 1%
- #<compiled -0x73a15eecd6f5e94> 1 1%
- eval 1 1%
- find-image 1 1%
image-search-load-path 1 1%
- timer-event-handler 1 1%
- timer-activate-when-idle 1 1%
- timer--activate 1 1%
timer--time-less-p 1 1%
On Wed, Apr 29, 2020 at 7:16 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Will Bush <will.g.bush <at> gmail.com>
> > Date: Wed, 29 Apr 2020 06:59:42 -0500
> > Cc: Robert Pluim <rpluim <at> gmail.com>, "Basil L. Contovounesios" <
> contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org,
> > James Cloos <cloos <at> jhcloos.com>
> >
> > It would be good to know what happens in Emacs during those 88
> > seconds. Please try using "M-x profiler" to find out.
> >
> > Here's what I get with `M-x profiler-start`, using the default cpu
> sampling,
> > `C-y` the character into a scratch buffer, wait for the character to
> show up,
> > `M-x profiler-stop`, and start `M-x profiler-report`:
>
> You shouldn't invoke profiler-stop, it affects the profile. Just
> profiler-start, do what you want to profile, then profiler-report.
>
> From what you posted, it looks like GC is a major player, but it's
> hard to be sure (and 88 sec is a lot of time for a GC). Please show
> the profile collected as suggested above.
>
> Thanks.
>
On Wed, Apr 29, 2020 at 7:16 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Will Bush <will.g.bush <at> gmail.com>
> > Date: Wed, 29 Apr 2020 06:59:42 -0500
> > Cc: Robert Pluim <rpluim <at> gmail.com>, "Basil L. Contovounesios" <
> contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org,
> > James Cloos <cloos <at> jhcloos.com>
> >
> > It would be good to know what happens in Emacs during those 88
> > seconds. Please try using "M-x profiler" to find out.
> >
> > Here's what I get with `M-x profiler-start`, using the default cpu
> sampling,
> > `C-y` the character into a scratch buffer, wait for the character to
> show up,
> > `M-x profiler-stop`, and start `M-x profiler-report`:
>
> You shouldn't invoke profiler-stop, it affects the profile. Just
> profiler-start, do what you want to profile, then profiler-report.
>
> From what you posted, it looks like GC is a major player, but it's
> hard to be sure (and 88 sec is a lot of time for a GC). Please show
> the profile collected as suggested above.
>
> Thanks.
>
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 29 Apr 2020 12:51:01 GMT) Full text and rfc822 format available.Message #59 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Robert Pluim <rpluim <at> gmail.com> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Eli Zaretskii <eliz <at> gnu.org>, 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 29 Apr 2020 14:50:33 +0200
>>>>> On Wed, 29 Apr 2020 07:42:20 -0500, Will Bush <will.g.bush <at> gmail.com> said:
Will> Did you see my other message that I forwarded where I forgot to CC
Will> everyone? I
Will> was able to switch between a bunch of revisions of the master branch to see
Will> where the performance issue started, and it appears to have started with
Will> commit
Will> (88efc736f5 Default cairo to enabled). I was hoping that would narrow it
Will> down.
Will> Maybe an upstream bug needs to be reported.
How many fonts do you have installed in the slow case? Is it possible
that 'fc-cache' needs to be rerun? (I have about 3000 installed here).
Robert
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 29 Apr 2020 14:32:01 GMT) Full text and rfc822 format available.Message #62 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: contovob <at> tcd.ie, rpluim <at> gmail.com, 40733 <at> debbugs.gnu.org, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 29 Apr 2020 17:30:42 +0300
> From: Will Bush <will.g.bush <at> gmail.com> > Date: Wed, 29 Apr 2020 07:42:20 -0500 > Cc: Robert Pluim <rpluim <at> gmail.com>, "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, > James Cloos <cloos <at> jhcloos.com> > > Did you see my other message that I forwarded where I forgot to CC everyone? I > was able to switch between a bunch of revisions of the master branch to see > where the performance issue started, and it appears to have started with commit > (88efc736f5 Default cairo to enabled). I was hoping that would narrow it down. I don't think it does. And the profile you show doesn't seem to be pointing at Emacs as the culprit, since all the functions shown are unrelated to displaying characters. So perhaps Robert is right, and some font-related subsystem of your OS is what takes time here.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 01 Jun 2020 11:20:02 GMT) Full text and rfc822 format available.Message #65 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Robert Pluim <rpluim <at> gmail.com>, 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 1 Jun 2020 06:19:02 -0500
[Message part 1 (text/plain, inline)]
I got distracted with yak shaving other things and circled back around to this issue. I was reinstalling NixOS on my laptop to try my hand at getting LUKS encryption working and decided to try to replicate the issue on there. I was able to, but that's not too surprising since the whole point of NixOS is reproducible environments. I decided to try reproduce it in Manjaro on my laptop from a "live CD" burned to a usb drive. Well that attempt got thwarted by attempting to install a rust based AUR helper which ate up all my RAM (on my old laptop) and started swapping to my usb drive. (I was trying to get an AUR helper to install google fonts) So I installed virt-manager (et al) (on my main computer) and Manjaro in a virtual machine. I built Emacs from source using `make` and `make install` from the latest in the master branch in git://git.savannah.gnu.org/emacs.git. Then I installed google fonts from https://aur.archlinux.org/packages/ttf-google-fonts-git/ ... and... no issue dammit. So I got my local machine back to the state where the issues occurred. `fc-list | rg -i google > fonts.txt` and use the power of Emacs to turn the ~1800 fonts into a list of strings I can set to `face-ignored-fonts` variable. I was excited to see that ignoring all 1800+ fonts fixed the perf issue. So I binary searched through them commenting them out and narrowed it down to one.. damn font "Adobe Blank". And sure enough (on my local NixOS machine): λ ~/ time emacs -Q --eval '(message "︵")' -kill emacs -Q --eval '(message "︵")' -kill 82.35s user 0.03s system 99% cpu 1:22.56 total λ ~/ time emacs -Q --eval "(progn (setq face-ignored-fonts '(\"Adobe Blank\")) (message \"︵\"))" -kill emacs -Q --eval -kill 0.22s user 0.02s system 68% cpu 0.349 total AHHHH!!!! I open up Manjaro in the virtual machine and: git clone https://github.com/adobe-fonts/adobe-blank.git cd adobe-blank sudo cp AdobeBlank.ttf /usr/share/fonts/ fc-cache time emacs -Q --eval '(message "︵")' -kill And it took 4 minutes in the virtual machine! Turns out that https://aur.archlinux.org/packages/ttf-google-fonts-git/ didn't have Adobe Blank font. Please try it and see if you can repro! Also, please note that the character I have been testing with is not the only one were this issue shows up. I have run into the issue when grep for things using deadgrep, but I didn't spend the time to narrow down to an exact character in those cases. On Wed, Apr 29, 2020 at 9:31 AM Eli Zaretskii <eliz <at> gnu.org> wrote: > > From: Will Bush <will.g.bush <at> gmail.com> > > Date: Wed, 29 Apr 2020 07:42:20 -0500 > > Cc: Robert Pluim <rpluim <at> gmail.com>, "Basil L. Contovounesios" < > contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, > > James Cloos <cloos <at> jhcloos.com> > > > > Did you see my other message that I forwarded where I forgot to CC > everyone? I > > was able to switch between a bunch of revisions of the master branch to > see > > where the performance issue started, and it appears to have started with > commit > > (88efc736f5 Default cairo to enabled). I was hoping that would narrow it > down. > > I don't think it does. > > And the profile you show doesn't seem to be pointing at Emacs as the > culprit, since all the functions shown are unrelated to displaying > characters. So perhaps Robert is right, and some font-related > subsystem of your OS is what takes time here. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 01 Jun 2020 11:45:02 GMT) Full text and rfc822 format available.Message #68 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> gmail.com> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 1 Jun 2020 11:44:10 +0000
On Mon, Jun 1, 2020 at 11:20 AM Will Bush <will.g.bush <at> gmail.com> wrote: > git clone https://github.com/adobe-fonts/adobe-blank.git > cd adobe-blank > sudo cp AdobeBlank.ttf /usr/share/fonts/ > fc-cache > time emacs -Q --eval '(message "︵")' -kill > > And it took 4 minutes in the virtual machine! > Please try it and see if you can repro! It's taking a while here (pretty standard GNU/Linux x86_64 system), but something on the order of 20 seconds, not 4 minutes. in ftcrfont.c: pat = ftfont_entity_pattern (entity, pixel_size); FcConfigSubstitute (NULL, pat, FcMatchPattern); FcDefaultSubstitute (pat); match = FcFontMatch (NULL, pat, &result); <=========== ftfont_fix_match (pat, match); This is where it spends so much time. "perf record emacs -Q" suggests it's a function called FcCharSetSubtractCount. (You might try running that on your setup, too).
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 01 Jun 2020 15:16:01 GMT) Full text and rfc822 format available.Message #71 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> gmail.com> Cc: contovob <at> tcd.ie, 40733 <at> debbugs.gnu.org, rpluim <at> gmail.com, will.g.bush <at> gmail.com, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 01 Jun 2020 18:15:32 +0300
> From: Pip Cet <pipcet <at> gmail.com> > Date: Mon, 1 Jun 2020 11:44:10 +0000 > Cc: Eli Zaretskii <eliz <at> gnu.org>, "Basil L. Contovounesios" <contovob <at> tcd.ie>, Robert Pluim <rpluim <at> gmail.com>, > 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> > > On Mon, Jun 1, 2020 at 11:20 AM Will Bush <will.g.bush <at> gmail.com> wrote: > > git clone https://github.com/adobe-fonts/adobe-blank.git > > cd adobe-blank > > sudo cp AdobeBlank.ttf /usr/share/fonts/ > > fc-cache > > time emacs -Q --eval '(message "︵")' -kill > > > > And it took 4 minutes in the virtual machine! > > Please try it and see if you can repro! > > It's taking a while here (pretty standard GNU/Linux x86_64 system), > but something on the order of 20 seconds, not 4 minutes. > > in ftcrfont.c: > > pat = ftfont_entity_pattern (entity, pixel_size); > FcConfigSubstitute (NULL, pat, FcMatchPattern); > FcDefaultSubstitute (pat); > match = FcFontMatch (NULL, pat, &result); <=========== > ftfont_fix_match (pat, match); > > This is where it spends so much time. "perf record emacs -Q" suggests > it's a function called FcCharSetSubtractCount. (You might try running > that on your setup, too). Thanks. From what I see in the net search, this is a very large font, created for some very special circumstances. Not sure we should spend time on this issue. Maybe submit a bug report to Fontconfig folks.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Mon, 01 Jun 2020 15:52:01 GMT) Full text and rfc822 format available.Message #74 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: contovob <at> tcd.ie, 40733 <at> debbugs.gnu.org, rpluim <at> gmail.com, will.g.bush <at> gmail.com, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 1 Jun 2020 15:50:36 +0000
On Mon, Jun 1, 2020 at 3:15 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Thanks.
>
> From what I see in the net search, this is a very large font, created
> for some very special circumstances. Not sure we should spend time on
> this issue. Maybe submit a bug report to Fontconfig folks.
Every call to fontconfig takes a long time, and we call it 17 times...
But it looks like the code that varies pixel size is there for a
reason:
for (psize = pixel_size; ; psize++)
{
font_object = driver_list->driver->open_font (f, entity, psize);
if (NILP (font_object))
return Qnil;
font = XFONT_OBJECT (font_object);
if (font->average_width > 0 && font->height > 0)
break;
/* Avoid an infinite loop. */
if (psize > pixel_size + 15)
return Qnil;
}
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sun, 24 Apr 2022 14:21:02 GMT) Full text and rfc822 format available.Message #77 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Sun, 24 Apr 2022 16:20:07 +0200
Will Bush <will.g.bush <at> gmail.com> writes: > git clone https://github.com/adobe-fonts/adobe-blank.git > cd adobe-blank > sudo cp AdobeBlank.ttf /usr/share/fonts/ > fc-cache > time emacs -Q --eval '(message "︵")' -kill > > And it took 4 minutes in the virtual machine! I tried this on Debian/bookworm with Emacs 28.1 (and 29), but was unable to see anything odd -- but Emacs chose to use the Noto font for that character here. Are you still seeing this problem in recent Emacs/OS versions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org.
(Sun, 24 Apr 2022 14:21:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 18 May 2022 03:40:01 GMT) Full text and rfc822 format available.Message #82 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Lars Ingebrigtsen <larsi <at> gnus.org> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>, James Cloos <cloos <at> jhcloos.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Tue, 17 May 2022 22:39:37 -0500
[Message part 1 (text/plain, inline)]
Sorry for the late reply. I will create a Debian VM and see if I can replicate it with the latest Emacs version built from source and get back to you. I did notice in a internet search that there's another bug referencing this one https://mail.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00169.html On Sun, Apr 24, 2022 at 9:20 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote: > Will Bush <will.g.bush <at> gmail.com> writes: > > > git clone https://github.com/adobe-fonts/adobe-blank.git > > cd adobe-blank > > sudo cp AdobeBlank.ttf /usr/share/fonts/ > > fc-cache > > time emacs -Q --eval '(message "︵")' -kill > > > > And it took 4 minutes in the virtual machine! > > I tried this on Debian/bookworm with Emacs 28.1 (and 29), but was unable > to see anything odd -- but Emacs chose to use the Noto font for that > character here. > > Are you still seeing this problem in recent Emacs/OS versions? > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 18 May 2022 11:20:01 GMT) Full text and rfc822 format available.Message #85 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: contovob <at> tcd.ie, 40733 <at> debbugs.gnu.org, larsi <at> gnus.org, rpluim <at> gmail.com, cloos <at> jhcloos.com Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 18 May 2022 14:18:58 +0300
> From: Will Bush <will.g.bush <at> gmail.com> > Date: Tue, 17 May 2022 22:39:37 -0500 > Cc: Eli Zaretskii <eliz <at> gnu.org>, "Basil L. Contovounesios" <contovob <at> tcd.ie>, Robert Pluim <rpluim <at> gmail.com>, > 40733 <at> debbugs.gnu.org, James Cloos <cloos <at> jhcloos.com> > > Sorry for the late reply. I will create a Debian VM and see if I can replicate it with the latest Emacs version built > from source and get back to you. I did notice in a internet search that there's another bug referencing this one > https://mail.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00169.html That bug was solved long ago, and it wasn't about slow display, it was about crashing.
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Wed, 15 Jun 2022 12:42:02 GMT) Full text and rfc822 format available.Message #88 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, James Cloos <cloos <at> jhcloos.com>, Robert Pluim <rpluim <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Wed, 15 Jun 2022 14:40:47 +0200
Will Bush <will.g.bush <at> gmail.com> writes: > Sorry for the late reply. I will create a Debian VM and see if I can > replicate it with the latest Emacs version built from source and get > back to you. Hi, this was a month ago -- were you able to make any progress here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sun, 19 Jun 2022 21:07:02 GMT) Full text and rfc822 format available.Message #91 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Will Bush <will.g.bush <at> gmail.com> To: Lars Ingebrigtsen <larsi <at> gnus.org> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, James Cloos <cloos <at> jhcloos.com>, Robert Pluim <rpluim <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Sun, 19 Jun 2022 16:05:46 -0500
[Message part 1 (text/plain, inline)]
I am unable to replicate the issue now. I tried it on Debian 11 with Emacs 29.0.50 running in a VM and NixOS 22.11 Emacs 28.1 running natively. On Wed, Jun 15, 2022 at 7:41 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote: > Will Bush <will.g.bush <at> gmail.com> writes: > > > Sorry for the late reply. I will create a Debian VM and see if I can > > replicate it with the latest Emacs version built from source and get > > back to you. > > Hi, > > this was a month ago -- were you able to make any progress here? > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#40733; Package emacs.
(Sun, 19 Jun 2022 22:26:02 GMT) Full text and rfc822 format available.Message #94 received at 40733 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Will Bush <will.g.bush <at> gmail.com> Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 40733 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, James Cloos <cloos <at> jhcloos.com>, Robert Pluim <rpluim <at> gmail.com> Subject: Re: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Date: Mon, 20 Jun 2022 00:25:16 +0200
Will Bush <will.g.bush <at> gmail.com> writes: > I am unable to replicate the issue now. I tried it on Debian 11 with > Emacs 29.0.50 running in a VM and NixOS 22.11 Emacs 28.1 running > natively. Thanks. I guess that means that the problem may have gone away, so I'm closing this bug report. If you experience it again, please respond to the debbugs address and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org.
(Sun, 19 Jun 2022 22:26:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Mon, 18 Jul 2022 11:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.