* bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client
@ 2015-08-07 18:39 Neil Baylis
2021-09-19 22:29 ` Stefan Kangas
0 siblings, 1 reply; 4+ messages in thread
From: Neil Baylis @ 2015-08-07 18:39 UTC (permalink / raw)
To: 21211
[-- Attachment #1: Type: text/plain, Size: 5224 bytes --]
I think I'm seeing a slight regression in the behavior of the mouse wheel
with xterm-mouse-mode. This is when running in -nw mode, using Windows
PuTTY as a client, with ssh into a linux box where the emacs runs. I've
verified that it's nothing in my init.el or site-lisp files. I've verified
that the bad behavior described below does not happen when running on the
same host with a real xterm.
The problem seems to have begun with emacs 24.4. I verified with fresh
builds from source that it works with 24.3, but not with 24.4 or 24.5.
The problem:
When I scroll using the mouse wheel, the buffer scrolls as before, but
there's also a screen flash, and a complaint in the mini buffer: "M-[ m" is
undefined". It seems that emacs is seeing this escape sequence after each
movement of the mouse wheel. I have PuTTY set to report xterm mouse events,
and I have xterm-mouse-mode turned on in emacs.
I can work around this by adding a global-set-key to recognize the escape
sequence and ignore it. As yet, I don't know if my workaround breaks
anything else. The escape sequence means "Turn off all special character
attributes, e.g., blinking, bold, etc.". Here's the workaround I'm using:
(global-set-key (kbd "\e [ m") (lambda () (interactive) nil))
Here is the lossage output under various combinations of emacs version and
client. I notice that with 24.4 the character \230 is displayed differently
than in 24.3, don't know if that relates to the problem. These are all
started as emacs -q -nw. After emacs starts up, I enable xterm-mouse-mode,
and then do a single scroll down with the mouse wheel:
This is emacs 24.3 with the PuTTY client. The bad behavior is not seen in
this case.
ESC [ > 0 ; 1 3 6 ; 0 c ESC x x t e r m - m o u s e
- m o d e RET ESC [ M a \230 % ESC [ M # \230 % C-h
l
This is emacs 24.3 with the genuine xterm client. The bad behavior is not
seen in this case.
ESC [ > 0 ; 2 7 8 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0
/ 0 0 0 0 / 0 0 0 0 ESC \ ESC x x t e r m - m o u s
e - m o d e RET ESC [ < 6 5 ; 5 0 ; 1 3 M C-h l
This is emacs 24.4 with the PuTTY client. The bad behavior is seen in this
case.
ESC [ > 0 ; 1 3 6 ; 0 c ESC x x t e r m - m o u s e
- m o d e RET ESC [ M a  K ESC [ M #  K C-h
l
This is emacs 24.4 with the genuine xterm client. The bad behavior is not
seen in this case.
ESC [ > 0 ; 2 7 8 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0
/ 0 0 0 0 / 0 0 0 0 ESC \ ESC x x t e r m - m o u s
e - m o d e RET ESC [ < 6 5 ; 9 6 ; 4 2 M C-h l$
Pasted below is the output from M-x report-emacs-bug on the failing
version. I have also tried emacs 24.5 and found the same bad behavior with
the PuTTY client.
In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
of 2015-07-30 on moes
System Description: Debian GNU/Linux 7.7 (wheezy)
Configured using:
`configure --with-xpm=no --with-gif=no --with-tiff=no'
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
tooltip-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
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC [ > 0 ; 1 3 6 ; 0 c ESC x r e p o r t - e m a c
s - b u g RET
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils xterm time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 77501 7411)
(symbols 48 17540 0)
(miscs 40 70 113)
(strings 32 9242 4336)
(string-bytes 1 248382)
(vectors 16 7099)
(vector-slots 8 341403 33128)
(floats 8 65 270)
(intervals 56 155 0)
(buffers 960 12)
(heap 1024 7622 527))
[-- Attachment #2: Type: text/html, Size: 15903 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client
2015-08-07 18:39 bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client Neil Baylis
@ 2021-09-19 22:29 ` Stefan Kangas
2021-09-20 4:47 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Kangas @ 2021-09-19 22:29 UTC (permalink / raw)
To: Neil Baylis; +Cc: 21211
Neil Baylis <neil.baylis@gmail.com> writes:
> I think I'm seeing a slight regression in the behavior of the mouse wheel with xterm-mouse-mode. This is when running in -nw mode, using
> Windows PuTTY as a client, with ssh into a linux box where the emacs runs. I've verified that it's nothing in my init.el or site-lisp files. I've
> verified that the bad behavior described below does not happen when running on the same host with a real xterm.
>
> The problem seems to have begun with emacs 24.4. I verified with fresh builds from source that it works with 24.3, but not with 24.4 or
> 24.5.
>
> The problem:
>
> When I scroll using the mouse wheel, the buffer scrolls as before, but there's also a screen flash, and a complaint in the mini buffer: "M-[
> m" is undefined". It seems that emacs is seeing this escape sequence after each movement of the mouse wheel. I have PuTTY set to
> report xterm mouse events, and I have xterm-mouse-mode turned on in emacs.
(That was 6 years ago.)
Are you still seeing this issue on a recent version of Emacs, such as
27.1?
> I can work around this by adding a global-set-key to recognize the escape sequence and ignore it. As yet, I don't know if my workaround
> breaks anything else. The escape sequence means "Turn off all special character attributes, e.g., blinking, bold, etc.". Here's the
> workaround I'm using:
>
> (global-set-key (kbd "\e [ m") (lambda () (interactive) nil))
>
> Here is the lossage output under various combinations of emacs version and client. I notice that with 24.4 the character \230 is displayed
> differently than in 24.3, don't know if that relates to the problem. These are all started as emacs -q -nw. After emacs starts up, I enable
> xterm-mouse-mode, and then do a single scroll down with the mouse wheel:
>
> This is emacs 24.3 with the PuTTY client. The bad behavior is not seen in this case.
>
>
>
> ESC [ > 0 ; 1 3 6 ; 0 c ESC x x t e r m - m o u s e
>
> - m o d e RET ESC [ M a \230 % ESC [ M # \230 % C-h
>
> l
>
>
>
>
>
>
>
> This is emacs 24.3 with the genuine xterm client. The bad behavior is not seen in this case.
>
>
>
> ESC [ > 0 ; 2 7 8 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0
>
> / 0 0 0 0 / 0 0 0 0 ESC \ ESC x x t e r m - m o u s
>
> e - m o d e RET ESC [ < 6 5 ; 5 0 ; 1 3 M C-h l
>
>
>
>
>
>
>
>
>
> This is emacs 24.4 with the PuTTY client. The bad behavior is seen in this case.
>
>
>
> ESC [ > 0 ; 1 3 6 ; 0 c ESC x x t e r m - m o u s e
>
> - m o d e RET ESC [ M a  K ESC [ M #  K C-h
>
> l
>
>
>
>
>
>
>
> This is emacs 24.4 with the genuine xterm client. The bad behavior is not seen in this case.
>
>
>
> ESC [ > 0 ; 2 7 8 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0
>
> / 0 0 0 0 / 0 0 0 0 ESC \ ESC x x t e r m - m o u s
>
> e - m o d e RET ESC [ < 6 5 ; 9 6 ; 4 2 M C-h l$
>
> Pasted below is the output from M-x report-emacs-bug on the failing version. I have also tried emacs 24.5 and found the same bad
> behavior with the PuTTY client.
>
> In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
>
> of 2015-07-30 on moes
>
> System Description: Debian GNU/Linux 7.7 (wheezy)
>
>
>
> Configured using:
>
> `configure --with-xpm=no --with-gif=no --with-tiff=no'
>
>
>
> Important settings:
>
> value of $LANG: en_US.UTF-8
>
> locale-coding-system: utf-8-unix
>
>
>
> Major mode: Fundamental
>
>
>
> Minor modes in effect:
>
> tooltip-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
>
> auto-composition-mode: t
>
> auto-encryption-mode: t
>
> auto-compression-mode: t
>
> buffer-read-only: t
>
> line-number-mode: t
>
> transient-mark-mode: t
>
>
>
> Recent input:
>
> ESC [ > 0 ; 1 3 6 ; 0 c ESC x r e p o r t - e m a c
>
> s - b u g RET
>
>
>
> Recent messages:
>
> For information about GNU Emacs and the GNU system, type C-h C-a.
>
>
>
> Load-path shadows:
>
> None found.
>
>
>
> Features:
>
> (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
>
> easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
>
> mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
>
> mm-util help-fns mail-prsvr mail-utils xterm time-date tooltip electric
>
> uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
>
> dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
>
> prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
>
> mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
>
> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
>
> japanese hebrew greek romanian slovak czech european ethiopic indian
>
> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
>
> minibuffer 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 make-network-process
>
> dbusbind gfilenotify dynamic-setting system-font-setting
>
> font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
>
>
>
> Memory information:
>
> ((conses 16 77501 7411)
>
> (symbols 48 17540 0)
>
> (miscs 40 70 113)
>
> (strings 32 9242 4336)
>
> (string-bytes 1 248382)
>
> (vectors 16 7099)
>
> (vector-slots 8 341403 33128)
>
> (floats 8 65 270)
>
> (intervals 56 155 0)
>
> (buffers 960 12)
>
> (heap 1024 7622 527))
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client
2021-09-19 22:29 ` Stefan Kangas
@ 2021-09-20 4:47 ` Eli Zaretskii
2021-09-20 6:09 ` Stefan Kangas
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2021-09-20 4:47 UTC (permalink / raw)
To: Stefan Kangas; +Cc: neil.baylis, 21211
> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 19 Sep 2021 15:29:54 -0700
> Cc: 21211@debbugs.gnu.org
>
> > When I scroll using the mouse wheel, the buffer scrolls as before, but there's also a screen flash, and a complaint in the mini buffer: "M-[
> > m" is undefined". It seems that emacs is seeing this escape sequence after each movement of the mouse wheel. I have PuTTY set to
> > report xterm mouse events, and I have xterm-mouse-mode turned on in emacs.
>
> (That was 6 years ago.)
>
> Are you still seeing this issue on a recent version of Emacs, such as
> 27.1?
I don't, FWIW.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client
2021-09-20 4:47 ` Eli Zaretskii
@ 2021-09-20 6:09 ` Stefan Kangas
0 siblings, 0 replies; 4+ messages in thread
From: Stefan Kangas @ 2021-09-20 6:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: neil.baylis, 21211-done
Eli Zaretskii <eliz@gnu.org> writes:
>> Are you still seeing this issue on a recent version of Emacs, such as
>> 27.1?
>
> I don't, FWIW.
OK, let's assume the problem has gone away or been fixed. I'm therefore
closing this bug report.
If this conclusion is incorrect and this is still an issue, please reply
to this email (use "Reply to all" in your email client) and we can
reopen the bug report.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-09-20 6:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 18:39 bug#21211: 24.4; Possible regression in xterm mouse handling with PuTTY client Neil Baylis
2021-09-19 22:29 ` Stefan Kangas
2021-09-20 4:47 ` Eli Zaretskii
2021-09-20 6:09 ` Stefan Kangas
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).