bug#49544: 26.3; shift arrow command runaway

bug#49544: 26.3; shift arrow command runaway

[Kunz, Chris via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

When I try to select a region using shift+arrow, if I hold the key combination down for a second or two it will continue selecting the text after the keys are released. It appears to enter an infinite loop and only stops after reaching the end (or beginning) of the buffer.

The arrow key alone does not show the same behavior. This is reproducible across major modes.


In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
of 2020-03-26, modified by Debian built on lcy01-amd64-020
Windowing system distributor 'HC-Consult', version 11.0.12008001
System Description:        Ubuntu 20.04.2 LTS

Recent messages:
Loading /etc/emacs/site-start.d/00debian.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
previous-line: Beginning of buffer [36 times]
C-x r e is undefined

Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --enable-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --build
x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
--with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-mailutils --with-x=yes
--with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs-mEZBk7/emacs-26.3+1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: C.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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util 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 menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95135 6373)
(symbols 48 20402 1)
(miscs 40 49 118)
(strings 32 28440 1444)
(string-bytes 1 751572)
(vectors 16 13907)
(vector-slots 8 500794 7396)
(floats 8 50 79)
(intervals 56 256 0)
(buffers 992 12))

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

bug#49544: 26.3; shift arrow command runaway

[Eli Zaretskii]

> Date: Tue, 13 Jul 2021 14:15:06 +0000
> From:  "Kunz, Chris" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When I try to select a region using shift+arrow, if I hold the key combination down for a second or two it will
> continue selecting the text after the keys are released. It appears to enter an infinite loop and only stops after
> reaching the end (or beginning) of the buffer.
> 
>  
> 
> The arrow key alone does not show the same behavior. This is reproducible across major modes.

Is this some "accessibility" feature of your system, perhaps?  There's
no such feature in Emacs, AFAIK.

bug#49544: 26.3; shift arrow command runaway

[Kunz, Chris via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Emacs is running under WSL (Ubuntu).  It doesn't happen in any application under Windows 10 (including GNU Emacs 25.2.1 compiled for Windows).  It also doesn't happen in the xterm window running under WSL.  It could be WSL or VcXsrv.  I will try to move to WSL 2 and see if that solves the issue.

Thanks,
Chris

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Tuesday, July 13, 2021 10:41
To: Kunz, Chris <ckunz@anl.gov>
Cc: 49544@debbugs.gnu.org
Subject: Re: bug#49544: 26.3; shift arrow command runaway

> Date: Tue, 13 Jul 2021 14:15:06 +0000
> From:  "Kunz, Chris" via "Bug reports for GNU Emacs,  the Swiss army 
> knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When I try to select a region using shift+arrow, if I hold the key 
> combination down for a second or two it will continue selecting the 
> text after the keys are released. It appears to enter an infinite loop and only stops after reaching the end (or beginning) of the buffer.
> 
>  
> 
> The arrow key alone does not show the same behavior. This is reproducible across major modes.

Is this some "accessibility" feature of your system, perhaps?  There's no such feature in Emacs, AFAIK.

bug#49544: 26.3; shift arrow command runaway

[Lars Ingebrigtsen]

"Kunz, Chris" <ckunz@anl.gov> writes:

> Emacs is running under WSL (Ubuntu).  It doesn't happen in any
> application under Windows 10 (including GNU Emacs 25.2.1 compiled for
> Windows).  It also doesn't happen in the xterm window running under
> WSL.  It could be WSL or VcXsrv.  I will try to move to WSL 2 and see
> if that solves the issue.

This was a month ago -- did you make any progress in identifying what
the issue might have been?

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

bug#49544: 26.3; shift arrow command runaway

[Lars Ingebrigtsen]

(Just re-sending to the debbugs address.)

"Kunz, Chris" <ckunz@anl.gov> writes:

> No.  I uninstalled WSL 1 and installed WSL 2, and reinstalled Emacs.  No change.
>
> I reduced the repeat-rate for the keyboard in WSL 2 and that didn't help either.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: Lars Ingebrigtsen <larsi@gnus.org> 
> Sent: Wednesday, August 11, 2021 15:40
> To: Kunz, Chris <ckunz@anl.gov>
> Cc: Eli Zaretskii <eliz@gnu.org>; 49544@debbugs.gnu.org
> Subject: Re: bug#49544: 26.3; shift arrow command runaway
>
> "Kunz, Chris" <ckunz@anl.gov> writes:
>
>> Emacs is running under WSL (Ubuntu).  It doesn't happen in any 
>> application under Windows 10 (including GNU Emacs 25.2.1 compiled for 
>> Windows).  It also doesn't happen in the xterm window running under 
>> WSL.  It could be WSL or VcXsrv.  I will try to move to WSL 2 and see 
>> if that solves the issue.
>
> This was a month ago -- did you make any progress in identifying what
>> the issue might have been?