* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
@ 2020-04-20 11:05 Will Bush
2020-04-20 15:52 ` Robert Pluim
2020-04-20 22:48 ` Basil L. Contovounesios
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2020-04-20 11:05 UTC (permalink / raw)
To: 40733
[-- Attachment #1: Type: text/plain, Size: 32692 bytes --]
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))
[-- Attachment #2: Type: text/html, Size: 33036 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 11:05 bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Will Bush
@ 2020-04-20 15:52 ` Robert Pluim
2020-04-20 16:13 ` Eli Zaretskii
2020-04-20 20:20 ` Alan Third
2020-04-20 22:48 ` Basil L. Contovounesios
1 sibling, 2 replies; 30+ messages in thread
From: Robert Pluim @ 2020-04-20 15:52 UTC (permalink / raw)
To: Will Bush; +Cc: 40733
>>>>> On Mon, 20 Apr 2020 06:05:58 -0500, Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 15:52 ` Robert Pluim
@ 2020-04-20 16:13 ` Eli Zaretskii
2020-04-20 21:27 ` Will Bush
2020-04-20 20:20 ` Alan Third
1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2020-04-20 16:13 UTC (permalink / raw)
To: Robert Pluim; +Cc: 40733, will.g.bush
> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 20 Apr 2020 17:52:02 +0200
> Cc: 40733@debbugs.gnu.org
>
> FWIW I donʼt see this on GNU/Linux.
And I don't see this on MS-Windows, FWIW.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 15:52 ` Robert Pluim
2020-04-20 16:13 ` Eli Zaretskii
@ 2020-04-20 20:20 ` Alan Third
1 sibling, 0 replies; 30+ messages in thread
From: Alan Third @ 2020-04-20 20:20 UTC (permalink / raw)
To: Robert Pluim; +Cc: 40733, Will Bush
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@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 16:13 ` Eli Zaretskii
@ 2020-04-20 21:27 ` Will Bush
0 siblings, 0 replies; 30+ messages in thread
From: Will Bush @ 2020-04-20 21:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Robert Pluim, 40733
[-- Attachment #1.1.1: Type: text/plain, Size: 4265 bytes --]
>
> 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@gmail.com>
AuthorDate: Mon May 28 13:33:08 2018 -0400
Commit: Matthew Bauer <mjbauer95@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@dfinity.org>
AuthorDate: Tue Oct 22 16:40:15 2019 -0700
Commit: John Wiegley <john@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
[-- Attachment #1.1.2: Type: text/html, Size: 6292 bytes --]
[-- Attachment #1.2: Screenshot from 2020-04-20 14-15-29.png --]
[-- Type: image/png, Size: 114102 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: unum-output.txt --]
[-- Type: text/plain; charset="US-ASCII"; name="unum-output.txt", Size: 914 bytes --]
λ ~/Downloads/ wget http://www.fourmilab.ch/webtools/unum/download/unum.tar.gz
--2020-04-20 13:44:11-- http://www.fourmilab.ch/webtools/unum/download/unum.tar.gz
Resolving www.fourmilab.ch (www.fourmilab.ch)... 52.28.236.0, 2a05:d014:d43:3101:c6ee:ea42:3836:6cbf
Connecting to www.fourmilab.ch (www.fourmilab.ch)|52.28.236.0|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1416635 (1.4M) [application/x-gzip]
Saving to: ‘unum.tar.gz’
unum.tar.gz 100%[========================================>] 1.35M 627KB/s in 2.2s
2020-04-20 13:44:13 (627 KB/s) - ‘unum.tar.gz’ saved [1416635/1416635]
λ ~/Downloads/ tar -zxvf unum.tar.gz
unum.pl
λ ~/Downloads/ perl -CA unum.pl ︵
Octal Decimal Hex HTML Character Unicode
0177065 65077 0xFE35 ︵ "︵" PRESENTATION FORM FOR VERTICAL LEFT PARENTHESIS
λ ~/Downloads/
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 11:05 bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Will Bush
2020-04-20 15:52 ` Robert Pluim
@ 2020-04-20 22:48 ` Basil L. Contovounesios
2020-04-21 10:01 ` Robert Pluim
1 sibling, 1 reply; 30+ messages in thread
From: Basil L. Contovounesios @ 2020-04-20 22:48 UTC (permalink / raw)
To: Will Bush; +Cc: 40733
Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-20 22:48 ` Basil L. Contovounesios
@ 2020-04-21 10:01 ` Robert Pluim
2020-04-21 12:19 ` Will Bush
0 siblings, 1 reply; 30+ messages in thread
From: Robert Pluim @ 2020-04-21 10:01 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 40733, Will Bush
>>>>> On Mon, 20 Apr 2020 23:48:48 +0100, "Basil L. Contovounesios" <contovob@tcd.ie> said:
Basil> Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-21 10:01 ` Robert Pluim
@ 2020-04-21 12:19 ` Will Bush
2020-04-21 13:19 ` Robert Pluim
2020-04-21 14:29 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2020-04-21 12:19 UTC (permalink / raw)
To: Robert Pluim; +Cc: Basil L. Contovounesios, 40733
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
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@gmail.com> wrote:
> >>>>> On Mon, 20 Apr 2020 23:48:48 +0100, "Basil L. Contovounesios" <
> contovob@tcd.ie> said:
>
> Basil> Will Bush <will.g.bush@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
>
[-- Attachment #2: Type: text/html, Size: 4394 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-21 12:19 ` Will Bush
@ 2020-04-21 13:19 ` Robert Pluim
2020-04-21 19:35 ` James Cloos
2020-04-21 14:29 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Robert Pluim @ 2020-04-21 13:19 UTC (permalink / raw)
To: Will Bush; +Cc: Basil L. Contovounesios, 40733
>>>>> On Tue, 21 Apr 2020 07:19:56 -0500, Will Bush <will.g.bush@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-21 12:19 ` Will Bush
2020-04-21 13:19 ` Robert Pluim
@ 2020-04-21 14:29 ` Eli Zaretskii
1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2020-04-21 14:29 UTC (permalink / raw)
To: Will Bush; +Cc: contovob, rpluim, 40733
> From: Will Bush <will.g.bush@gmail.com>
> Date: Tue, 21 Apr 2020 07:19:56 -0500
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 40733@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-21 13:19 ` Robert Pluim
@ 2020-04-21 19:35 ` James Cloos
2020-04-22 7:35 ` Robert Pluim
0 siblings, 1 reply; 30+ messages in thread
From: James Cloos @ 2020-04-21 19:35 UTC (permalink / raw)
To: Robert Pluim; +Cc: Basil L. Contovounesios, 40733, Will Bush
>>>>> "RP" == Robert Pluim <rpluim@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@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-21 19:35 ` James Cloos
@ 2020-04-22 7:35 ` Robert Pluim
2020-04-25 10:34 ` Will Bush
0 siblings, 1 reply; 30+ messages in thread
From: Robert Pluim @ 2020-04-22 7:35 UTC (permalink / raw)
To: James Cloos; +Cc: Basil L. Contovounesios, 40733, Will Bush
>>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos@jhcloos.com> said:
>>>>> "RP" == Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-22 7:35 ` Robert Pluim
@ 2020-04-25 10:34 ` Will Bush
[not found] ` <CA+aYz4RNB1-g5uUz-M-XuJEhZPGpA4X6n8NSiTCUdOMkpReFng@mail.gmail.com>
2020-04-25 13:50 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2020-04-25 10:34 UTC (permalink / raw)
To: Robert Pluim; +Cc: Basil L. Contovounesios, 40733, James Cloos
[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]
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@gmail.com> wrote:
> >>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos@jhcloos.com>
> said:
>
> >>>>> "RP" == Robert Pluim <rpluim@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
>
[-- Attachment #2: Type: text/html, Size: 5627 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: Fwd: bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
[not found] ` <CA+aYz4RNB1-g5uUz-M-XuJEhZPGpA4X6n8NSiTCUdOMkpReFng@mail.gmail.com>
@ 2020-04-25 13:34 ` Will Bush
0 siblings, 0 replies; 30+ messages in thread
From: Will Bush @ 2020-04-25 13:34 UTC (permalink / raw)
To: James Cloos, Basil L. Contovounesios, 40733, Robert Pluim
[-- Attachment #1: Type: text/plain, Size: 8529 bytes --]
I forgot to CC everyone.
---------- Forwarded message ---------
From: Will Bush <will.g.bush@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@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@nix-community>
AuthorDate: Tue Jan 14 12:10:25 2020 +0000
Commit: emacs-overlay <emacs-overlay@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@nix-community>
AuthorDate: Mon Jan 13 00:10:30 2020 +0000
Commit: emacs-overlay <emacs-overlay@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@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@gmail.com> wrote:
>
>> >>>>> On Tue, 21 Apr 2020 15:35:23 -0400, James Cloos <cloos@jhcloos.com>
>> said:
>>
>> >>>>> "RP" == Robert Pluim <rpluim@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
>>
>
[-- Attachment #2: Type: text/html, Size: 11356 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-25 10:34 ` Will Bush
[not found] ` <CA+aYz4RNB1-g5uUz-M-XuJEhZPGpA4X6n8NSiTCUdOMkpReFng@mail.gmail.com>
@ 2020-04-25 13:50 ` Eli Zaretskii
2020-04-29 11:59 ` Will Bush
1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2020-04-25 13:50 UTC (permalink / raw)
To: Will Bush; +Cc: contovob, rpluim, 40733, cloos
> From: Will Bush <will.g.bush@gmail.com>
> Date: Sat, 25 Apr 2020 05:34:23 -0500
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 40733@debbugs.gnu.org,
> James Cloos <cloos@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-25 13:50 ` Eli Zaretskii
@ 2020-04-29 11:59 ` Will Bush
2020-04-29 12:16 ` Eli Zaretskii
0 siblings, 1 reply; 30+ messages in thread
From: Will Bush @ 2020-04-29 11:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Basil L. Contovounesios, Robert Pluim, 40733, James Cloos
[-- Attachment #1: Type: text/plain, Size: 7821 bytes --]
>
> 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@gnu.org> wrote:
> > From: Will Bush <will.g.bush@gmail.com>
> > Date: Sat, 25 Apr 2020 05:34:23 -0500
> > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 40733@debbugs.gnu.org,
> > James Cloos <cloos@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.
>
[-- Attachment #2: Type: text/html, Size: 12795 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-29 11:59 ` Will Bush
@ 2020-04-29 12:16 ` Eli Zaretskii
2020-04-29 12:42 ` Will Bush
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2020-04-29 12:16 UTC (permalink / raw)
To: Will Bush; +Cc: contovob, rpluim, 40733, cloos
> From: Will Bush <will.g.bush@gmail.com>
> Date: Wed, 29 Apr 2020 06:59:42 -0500
> Cc: Robert Pluim <rpluim@gmail.com>, "Basil L. Contovounesios" <contovob@tcd.ie>, 40733@debbugs.gnu.org,
> James Cloos <cloos@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-29 12:16 ` Eli Zaretskii
@ 2020-04-29 12:42 ` Will Bush
2020-04-29 12:50 ` Robert Pluim
2020-04-29 14:30 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2020-04-29 12:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Basil L. Contovounesios, Robert Pluim, 40733, James Cloos
[-- Attachment #1: Type: text/plain, Size: 12318 bytes --]
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@gnu.org> wrote:
> > From: Will Bush <will.g.bush@gmail.com>
> > Date: Wed, 29 Apr 2020 06:59:42 -0500
> > Cc: Robert Pluim <rpluim@gmail.com>, "Basil L. Contovounesios" <
> contovob@tcd.ie>, 40733@debbugs.gnu.org,
> > James Cloos <cloos@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@gnu.org> wrote:
> > From: Will Bush <will.g.bush@gmail.com>
> > Date: Wed, 29 Apr 2020 06:59:42 -0500
> > Cc: Robert Pluim <rpluim@gmail.com>, "Basil L. Contovounesios" <
> contovob@tcd.ie>, 40733@debbugs.gnu.org,
> > James Cloos <cloos@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.
>
[-- Attachment #2: Type: text/html, Size: 20278 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-29 12:42 ` Will Bush
@ 2020-04-29 12:50 ` Robert Pluim
2020-04-29 14:30 ` Eli Zaretskii
1 sibling, 0 replies; 30+ messages in thread
From: Robert Pluim @ 2020-04-29 12:50 UTC (permalink / raw)
To: Will Bush; +Cc: Basil L. Contovounesios, 40733, James Cloos
>>>>> On Wed, 29 Apr 2020 07:42:20 -0500, Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-29 12:42 ` Will Bush
2020-04-29 12:50 ` Robert Pluim
@ 2020-04-29 14:30 ` Eli Zaretskii
2020-06-01 11:19 ` Will Bush
1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2020-04-29 14:30 UTC (permalink / raw)
To: Will Bush; +Cc: contovob, rpluim, 40733, cloos
> From: Will Bush <will.g.bush@gmail.com>
> Date: Wed, 29 Apr 2020 07:42:20 -0500
> Cc: Robert Pluim <rpluim@gmail.com>, "Basil L. Contovounesios" <contovob@tcd.ie>, 40733@debbugs.gnu.org,
> James Cloos <cloos@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-04-29 14:30 ` Eli Zaretskii
@ 2020-06-01 11:19 ` Will Bush
2020-06-01 11:44 ` Pip Cet
2022-04-24 14:20 ` Lars Ingebrigtsen
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2020-06-01 11:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Basil L. Contovounesios, Robert Pluim, 40733, James Cloos
[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]
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@gnu.org> wrote:
> > From: Will Bush <will.g.bush@gmail.com>
> > Date: Wed, 29 Apr 2020 07:42:20 -0500
> > Cc: Robert Pluim <rpluim@gmail.com>, "Basil L. Contovounesios" <
> contovob@tcd.ie>, 40733@debbugs.gnu.org,
> > James Cloos <cloos@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.
>
[-- Attachment #2: Type: text/html, Size: 4664 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-06-01 11:19 ` Will Bush
@ 2020-06-01 11:44 ` Pip Cet
2020-06-01 15:15 ` Eli Zaretskii
2022-04-24 14:20 ` Lars Ingebrigtsen
1 sibling, 1 reply; 30+ messages in thread
From: Pip Cet @ 2020-06-01 11:44 UTC (permalink / raw)
To: Will Bush; +Cc: Basil L. Contovounesios, 40733, James Cloos, Robert Pluim
On Mon, Jun 1, 2020 at 11:20 AM Will Bush <will.g.bush@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).
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-06-01 11:44 ` Pip Cet
@ 2020-06-01 15:15 ` Eli Zaretskii
2020-06-01 15:50 ` Pip Cet
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2020-06-01 15:15 UTC (permalink / raw)
To: Pip Cet; +Cc: contovob, 40733, rpluim, cloos, will.g.bush
> From: Pip Cet <pipcet@gmail.com>
> Date: Mon, 1 Jun 2020 11:44:10 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, "Basil L. Contovounesios" <contovob@tcd.ie>, Robert Pluim <rpluim@gmail.com>,
> 40733@debbugs.gnu.org, James Cloos <cloos@jhcloos.com>
>
> On Mon, Jun 1, 2020 at 11:20 AM Will Bush <will.g.bush@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-06-01 15:15 ` Eli Zaretskii
@ 2020-06-01 15:50 ` Pip Cet
0 siblings, 0 replies; 30+ messages in thread
From: Pip Cet @ 2020-06-01 15:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: contovob, 40733, rpluim, cloos, will.g.bush
On Mon, Jun 1, 2020 at 3:15 PM Eli Zaretskii <eliz@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;
}
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2020-06-01 11:19 ` Will Bush
2020-06-01 11:44 ` Pip Cet
@ 2022-04-24 14:20 ` Lars Ingebrigtsen
2022-05-18 3:39 ` Will Bush
1 sibling, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-24 14:20 UTC (permalink / raw)
To: Will Bush; +Cc: Basil L. Contovounesios, 40733, James Cloos, Robert Pluim
Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2022-04-24 14:20 ` Lars Ingebrigtsen
@ 2022-05-18 3:39 ` Will Bush
2022-05-18 11:18 ` Eli Zaretskii
2022-06-15 12:40 ` Lars Ingebrigtsen
0 siblings, 2 replies; 30+ messages in thread
From: Will Bush @ 2022-05-18 3:39 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Basil L. Contovounesios, 40733, Eli Zaretskii, Robert Pluim,
James Cloos
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
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@gnus.org> wrote:
> Will Bush <will.g.bush@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
>
[-- Attachment #2: Type: text/html, Size: 1728 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2022-05-18 3:39 ` Will Bush
@ 2022-05-18 11:18 ` Eli Zaretskii
2022-06-15 12:40 ` Lars Ingebrigtsen
1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2022-05-18 11:18 UTC (permalink / raw)
To: Will Bush; +Cc: contovob, 40733, larsi, rpluim, cloos
> From: Will Bush <will.g.bush@gmail.com>
> Date: Tue, 17 May 2022 22:39:37 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, "Basil L. Contovounesios" <contovob@tcd.ie>, Robert Pluim <rpluim@gmail.com>,
> 40733@debbugs.gnu.org, James Cloos <cloos@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2022-05-18 3:39 ` Will Bush
2022-05-18 11:18 ` Eli Zaretskii
@ 2022-06-15 12:40 ` Lars Ingebrigtsen
2022-06-19 21:05 ` Will Bush
1 sibling, 1 reply; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-15 12:40 UTC (permalink / raw)
To: Will Bush
Cc: Basil L. Contovounesios, 40733, Eli Zaretskii, James Cloos,
Robert Pluim
Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2022-06-15 12:40 ` Lars Ingebrigtsen
@ 2022-06-19 21:05 ` Will Bush
2022-06-19 22:25 ` Lars Ingebrigtsen
0 siblings, 1 reply; 30+ messages in thread
From: Will Bush @ 2022-06-19 21:05 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Basil L. Contovounesios, 40733, Eli Zaretskii, James Cloos,
Robert Pluim
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
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@gnus.org> wrote:
> Will Bush <will.g.bush@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
>
[-- Attachment #2: Type: text/html, Size: 1090 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters
2022-06-19 21:05 ` Will Bush
@ 2022-06-19 22:25 ` Lars Ingebrigtsen
0 siblings, 0 replies; 30+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-19 22:25 UTC (permalink / raw)
To: Will Bush
Cc: Basil L. Contovounesios, 40733, Eli Zaretskii, James Cloos,
Robert Pluim
Will Bush <will.g.bush@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
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-06-19 22:25 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-20 11:05 bug#40733: 28.0.50; Emacs locks up on paste (yank) of unicode characters Will Bush
2020-04-20 15:52 ` Robert Pluim
2020-04-20 16:13 ` Eli Zaretskii
2020-04-20 21:27 ` Will Bush
2020-04-20 20:20 ` Alan Third
2020-04-20 22:48 ` Basil L. Contovounesios
2020-04-21 10:01 ` Robert Pluim
2020-04-21 12:19 ` Will Bush
2020-04-21 13:19 ` Robert Pluim
2020-04-21 19:35 ` James Cloos
2020-04-22 7:35 ` Robert Pluim
2020-04-25 10:34 ` Will Bush
[not found] ` <CA+aYz4RNB1-g5uUz-M-XuJEhZPGpA4X6n8NSiTCUdOMkpReFng@mail.gmail.com>
2020-04-25 13:34 ` bug#40733: Fwd: " Will Bush
2020-04-25 13:50 ` Eli Zaretskii
2020-04-29 11:59 ` Will Bush
2020-04-29 12:16 ` Eli Zaretskii
2020-04-29 12:42 ` Will Bush
2020-04-29 12:50 ` Robert Pluim
2020-04-29 14:30 ` Eli Zaretskii
2020-06-01 11:19 ` Will Bush
2020-06-01 11:44 ` Pip Cet
2020-06-01 15:15 ` Eli Zaretskii
2020-06-01 15:50 ` Pip Cet
2022-04-24 14:20 ` Lars Ingebrigtsen
2022-05-18 3:39 ` Will Bush
2022-05-18 11:18 ` Eli Zaretskii
2022-06-15 12:40 ` Lars Ingebrigtsen
2022-06-19 21:05 ` Will Bush
2022-06-19 22:25 ` Lars Ingebrigtsen
2020-04-21 14:29 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).