bug#50192: Bug: Yank slow and cancels macro recording

bug#50192: Bug: Yank slow and cancels macro recording

[Seth Sevier]

The following procedure produces the message 'Not defining keyboard macro' in emacs -Q:

C-p
C-p
C-SPC
C-e
M-w
RET
C-x (
C-y
C-x )

C-y also takes several seconds to execute.


In GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-08-24 built on cryomech
Repository revision: 0c640b82f0b3d9a06156a61af0aeec11a2f98ba0
Repository branch: master
System Description: Debian GNU/Linux 11 (bullseye)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils kmacro time-date subr-x cl-loaddefs cl-lib term/st term/xterm
xterm byte-opt gv bytecomp byte-compile cconv iso-transl 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 easymenu
timer select scroll-bar mouse jit-lock font-lock syntax 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 button
loaddefs faces cus-face macroexp files window 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 56878 8401)
 (symbols 48 6816 2)
 (strings 32 18518 1911)
 (string-bytes 1 602694)
 (vectors 16 10752)
 (vector-slots 8 128932 8146)
 (floats 8 27 564)
 (intervals 56 729 3)
 (buffers 992 11))

bug#50192: Bug: Yank slow and cancels macro recording

[Eli Zaretskii]

> Date: Tue, 24 Aug 2021 14:09:46 -0400
> From: Seth Sevier <s.sevier@cryomech.com>
> 
> The following procedure produces the message 'Not defining keyboard macro' in emacs -Q:
> 
> C-p
> C-p
> C-SPC
> C-e
> M-w
> RET
> C-x (
> C-y
> C-x )
> 
> C-y also takes several seconds to execute.

I cannot reproduce this, FWIW.

bug#50192: Bug: Yank slow and cancels macro recording

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot reproduce this, FWIW.

I can't reproduce it either (and I'm using Debian/bullseye, like the bug
reporter).

Seth, are you using some kind of clipboard manager in Linux that may be
interfering with what Emacs is doing here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50192: Bug: Yank slow and cancels macro recording

[Seth Sevier]

My apologies, I neglected to say emacs -nw -Q.  I've done my work in an SSH session for too long I suppose!

I am running st, setting TERM=st-256color to TERM=xterm-256color resolves the issue, as well as switching to xfce4-terminal.

I've located an older Ubuntu machine on commit 17048030f52b359d3baa09fb8f7a7c8c308ba666.  The issue does not happen there, and does upon updating to the latest commit.
Unfortunately I can't verify if downgrading back to that commit works, on either machine running a make clean && make install gives me  'make: *** [Makefile:443: src] Error 2'.
Switching back to the Debian/bullseye apt binary on verison 27.1 does resolve the issue at least.

On Wed, Aug 25, 2021 at 01:39:09PM +0200, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot reproduce this, FWIW.
> 
> I can't reproduce it either (and I'm using Debian/bullseye, like the bug
> reporter).
> 
> Seth, are you using some kind of clipboard manager in Linux that may be
> interfering with what Emacs is doing here?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

bug#50192: Bug: Yank slow and cancels macro recording

[Lars Ingebrigtsen]

Seth Sevier <s.sevier@cryomech.com> writes:

> My apologies, I neglected to say emacs -nw -Q.  I've done my work in
> an SSH session for too long I suppose!
>
> I am running st, setting TERM=st-256color to TERM=xterm-256color
> resolves the issue, as well as switching to xfce4-terminal.

I can reproduce this under stterm with -nw on the current trunk -- any
yanking takes two seconds, and does cancel the macro.

In the shell that I opened stterm in, I also get:

erresc: unknown csi ESC[>4;1m
erresc: unknown csi ESC[>4m
erresc: unknown csi ESC[>4;1m
erresc: unknown csi ESC[>4m
erresc: unknown csi ESC[>4;1m

So I guess there's a bunch of stuff that doesn't work in stterm?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50192: Bug: Yank slow and cancels macro recording

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I can reproduce this under stterm with -nw on the current trunk -- any
> yanking takes two seconds, and does cancel the macro.

This should now be fixed on the trunk.  Can you give it a test?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50192: Bug: Yank slow and cancels macro recording

[Lars Ingebrigtsen]

Seth Sevier <s.sevier@cryomech.com> writes:

> I just tested it out, looks like it works now.

Thanks for testing; I'm closing this bug report, then.