GNU bug report logs - #23009
25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23009 in the body.
You can then email your comments to 23009 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates
Date: Mon, 14 Mar 2016 13:56:41 +0100

`xterm-mouse-mode' sends \e[?1005h to enable UTF-8 mouse coordinates,
but it never checks that the terminal actually supports that.  Then
`xterm-mouse--read-utf8-char' reads an UTF-8 sequence without checking
that the terminal actually sent one.  On terminals that don't support
UTF-8 coordinates (such as Chromium's hterm) this leads to garbage if
any mouse coordinate is larger than 127.  For example, when clicking in
the right part of the terminal in hterm, the menu opens and the
following is shown in lossage:

   ESC [ M SPC \237 F ESC [ M # \237 F [tmm-menubar-mouse]

Instead, this should have been interpreted as two events with
single-byte mouse coordinates.

I'd suggest the following (and will happily provide patches if
accepted):

- Don't enable UTF-8 coordinates at all.  It is too hard to figure out
  whether they are enabled.  Rather, err on the safe side and only use
  single-byte coordinates.  (The superior SGR mode, which doesn't suffer
  from this problem, should remain enabled.)

- In `xterm-mouse--read-number-from-terminal', specify a very short
  timeout.  The terminal will always write the entire escape sequence as
  a unit, so waiting only increases the chance to accidentially read
  unrelated events.

- As an optimization, provide a `read-byte' function written in C that
  reads a single byte without taking the current terminal encoding into
  account.



In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-03-14 built on REDACTED
Repository revision: 80ec484ac83e6965a843dabf766ade057ee1bc6a
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

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
  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

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase
cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 88738 7446)
 (symbols 48 19932 0)
 (miscs 40 463 186)
 (strings 32 14918 4643)
 (string-bytes 1 445677)
 (vectors 16 12226)
 (vector-slots 8 442799 4664)
 (floats 8 164 18)
 (intervals 56 206 0)
 (buffers 976 12)
 (heap 1024 30327 1014))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

Message #8 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Mon, 14 Mar 2016 18:43:03 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Mon, 14 Mar 2016 13:56:41 +0100
> 
> I'd suggest the following (and will happily provide patches if
> accepted):
> 
> - Don't enable UTF-8 coordinates at all.  It is too hard to figure out
>   whether they are enabled.  Rather, err on the safe side and only use
>   single-byte coordinates.  (The superior SGR mode, which doesn't suffer
>   from this problem, should remain enabled.)

How about providing a user option, off by default, to enable that?  A
user who knows that this works on her machine will then be able to use
the feature.

> - In `xterm-mouse--read-number-from-terminal', specify a very short
>   timeout.  The terminal will always write the entire escape sequence as
>   a unit, so waiting only increases the chance to accidentially read
>   unrelated events.

Won't this break when working on a remote machine via a slow link?

> - As an optimization, provide a `read-byte' function written in C that
>   reads a single byte without taking the current terminal encoding into
>   account.

You should be able to achieve the same effect by binding
keyboard-coding-system to no-conversion, no?

Message #11 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Mon, 14 Mar 2016 17:24:57 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Mo., 14. März 2016 um 17:43 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Mon, 14 Mar 2016 13:56:41 +0100
> >
> > I'd suggest the following (and will happily provide patches if
> > accepted):
> >
> > - Don't enable UTF-8 coordinates at all.  It is too hard to figure out
> >   whether they are enabled.  Rather, err on the safe side and only use
> >   single-byte coordinates.  (The superior SGR mode, which doesn't suffer
> >   from this problem, should remain enabled.)
>
> How about providing a user option, off by default, to enable that?  A
> user who knows that this works on her machine will then be able to use
> the feature.
>

I considered that, but then it would be impossible to have different
terminals with and without the option. Might still be a good idea, if it's
off by default.


>
> > - In `xterm-mouse--read-number-from-terminal', specify a very short
> >   timeout.  The terminal will always write the entire escape sequence as
> >   a unit, so waiting only increases the chance to accidentially read
> >   unrelated events.
>
> Won't this break when working on a remote machine via a slow link?
>

Maybe, haven't tried.


>
> > - As an optimization, provide a `read-byte' function written in C that
> >   reads a single byte without taking the current terminal encoding into
> >   account.
>
> You should be able to achieve the same effect by binding
> keyboard-coding-system to no-conversion, no?
>

Yes, but that feels kind of like an abstraction inversion. Still probably
good enough. As said, this is only an optimization.

[Message part 2 (text/html, inline)]

Message #14 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Mon, 14 Mar 2016 23:03:21 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Mo., 14. März 2016 um
18:24 Uhr:

> Eli Zaretskii <eliz <at> gnu.org> schrieb am Mo., 14. März 2016 um 17:43 Uhr:
>
>> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> > Date: Mon, 14 Mar 2016 13:56:41 +0100
>> >
>> > I'd suggest the following (and will happily provide patches if
>> > accepted):
>> >
>> > - Don't enable UTF-8 coordinates at all.  It is too hard to figure out
>> >   whether they are enabled.  Rather, err on the safe side and only use
>> >   single-byte coordinates.  (The superior SGR mode, which doesn't suffer
>> >   from this problem, should remain enabled.)
>>
>> How about providing a user option, off by default, to enable that?  A
>> user who knows that this works on her machine will then be able to use
>> the feature.
>>
>
> I considered that, but then it would be impossible to have different
> terminals with and without the option. Might still be a good idea, if it's
> off by default.
>

Added a patch. I've had to use latin-1 instead of no-conversion to prevent
resetting the meta mode.

[Message part 2 (text/html, inline)]

[0001-Add-customization-option-for-UTF-8-coordinates.patch (application/octet-stream, attachment)]

Message #17 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Tue, 15 Mar 2016 19:57:06 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Mon, 14 Mar 2016 23:03:21 +0000
> Cc: 23009 <at> debbugs.gnu.org
> 
> Added a patch. I've had to use latin-1 instead of no-conversion to prevent resetting the meta mode. 

Not sure I understand the problem you had with no-conversion.  Can you
elaborate?

> --- a/lisp/international/mule.el
> +++ b/lisp/international/mule.el
> @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
>    (set-keyboard-coding-system-internal coding-system terminal)
>    (setq keyboard-coding-system coding-system))
>  
> +(gv-define-setter keyboard-coding-system (coding-system &optional terminal)
> +  `(set-keyboard-coding-system ,coding-system ,terminal))

I don't think you can do that: mule.el is preloaded, while gv.el
isn't.

It isn't a catastrophe to temporarily switch keyboard encoding "the
dull way".

> +               ;; Use Latin-1 instead of no-conversion to avoid
> +               ;; flicker due to `set-keyboard-coding-system' changing
> +               ;; the meta mode.

Ah, so that's the problem...  Did you try raw-text instead?

And anyway, doesn't latin-1 give you trouble for bytes in the 128..159
range?

Other than that, I have no comments.  Let's wait for a few days to
give others time to chime in, if they want to.

Thanks.

Message #20 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 19 Mar 2016 17:15:10 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 15. März 2016 um 18:57 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Mon, 14 Mar 2016 23:03:21 +0000
> > Cc: 23009 <at> debbugs.gnu.org
> >
> > Added a patch. I've had to use latin-1 instead of no-conversion to
> prevent resetting the meta mode.
>
> Not sure I understand the problem you had with no-conversion.  Can you
> elaborate?
>
> > --- a/lisp/international/mule.el
> > +++ b/lisp/international/mule.el
> > @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
> >    (set-keyboard-coding-system-internal coding-system terminal)
> >    (setq keyboard-coding-system coding-system))
> >
> > +(gv-define-setter keyboard-coding-system (coding-system &optional
> terminal)
> > +  `(set-keyboard-coding-system ,coding-system ,terminal))
>
> I don't think you can do that: mule.el is preloaded, while gv.el
> isn't.
>
> It isn't a catastrophe to temporarily switch keyboard encoding "the
> dull way".
>

OK, done.


>
> > +               ;; Use Latin-1 instead of no-conversion to avoid
> > +               ;; flicker due to `set-keyboard-coding-system' changing
> > +               ;; the meta mode.
>
> Ah, so that's the problem...  Did you try raw-text instead?
>
>
Same issue, with both raw-text and no-conversion the
set-keyboard-coding-system function switches the meta mode between t and
nil, leading to flicker.
I guess if the meta mode was nil initially, it would flicker with latin-1.
I'm quite puzzled about this behavior and the meta mode in general now. It
seems that for this purpose (reading a single byte from the terminal) both
nil (ignore top bit) and t (treat top bit as meta) seem wrong, but both
lead to the correct result (i.e. the byte is returned as-is, without
interpretation of the top bit).
Ideally there were a function to read a single byte, ignoring the meta mode
and all conversions.


> And anyway, doesn't latin-1 give you trouble for bytes in the 128..159
> range?
>
>
It works at least in HTerm without flicker or other issues.

[Message part 2 (text/html, inline)]

Message #23 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 19 Mar 2016 17:16:13 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Sa., 19. März 2016 um
18:15 Uhr:

> Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 15. März 2016 um 18:57 Uhr:
>
>> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> > Date: Mon, 14 Mar 2016 23:03:21 +0000
>> > Cc: 23009 <at> debbugs.gnu.org
>> >
>> > Added a patch. I've had to use latin-1 instead of no-conversion to
>> prevent resetting the meta mode.
>>
>> Not sure I understand the problem you had with no-conversion.  Can you
>> elaborate?
>>
>> > --- a/lisp/international/mule.el
>> > +++ b/lisp/international/mule.el
>> > @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
>> >    (set-keyboard-coding-system-internal coding-system terminal)
>> >    (setq keyboard-coding-system coding-system))
>> >
>> > +(gv-define-setter keyboard-coding-system (coding-system &optional
>> terminal)
>> > +  `(set-keyboard-coding-system ,coding-system ,terminal))
>>
>> I don't think you can do that: mule.el is preloaded, while gv.el
>> isn't.
>>
>> It isn't a catastrophe to temporarily switch keyboard encoding "the
>> dull way".
>>
>
> OK, done.
>
>

Here's a new patch.

[Message part 2 (text/html, inline)]

[0001-Add-customization-option-for-UTF-8-coordinates.patch (application/octet-stream, attachment)]

Message #28 received at 23009-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23009-done <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Fri, 25 Mar 2016 13:18:51 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 19 Mar 2016 17:16:13 +0000
> Cc: 23009 <at> debbugs.gnu.org
> 
> Here's a new patch. 

Thanks, pushed.

Message #31 received at 23009-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009-done <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 26 Mar 2016 17:31:46 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 25. März 2016 um 11:19 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 19 Mar 2016 17:16:13 +0000
> > Cc: 23009 <at> debbugs.gnu.org
> >
> > Here's a new patch.
>
> Thanks, pushed.
>

Thanks, confirmed that it's now working in HTerm.

We still might consider solving the flicker problem for "no-conversion".
Honestly I don't understand the behavior of the meta mode at all: it seems
that for the purpose of read-char the meta-mode is completely ignored? If
so, would it make sense to use set-keyboard-coding-system-internal, which
doesn't appear to set the meta-mode?

[Message part 2 (text/html, inline)]

Message #34 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 26 Mar 2016 21:07:48 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 26 Mar 2016 17:31:46 +0000
> Cc: 23009-done <at> debbugs.gnu.org
> 
> We still might consider solving the flicker problem for "no-conversion". Honestly I don't understand the
> behavior of the meta mode at all: it seems that for the purpose of read-char the meta-mode is completely
> ignored? If so, would it make sense to use set-keyboard-coding-system-internal, which doesn't appear to set
> the meta-mode?

Hmm... what does current-input-mode return on HTerm in "emacs -Q"?  I
expect to see a non-nil, non-t value in the 3rd element of its return
value.  If that's so, then testing that value for identity with the
one we want to pass to set-input-meta-mode, and avoiding the latter
call if the mode is already what we want, might avoid the flickering.

Can you see if this is doable?

Message #37 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 26 Mar 2016 22:26:17 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 26. März 2016 um 19:08 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 26 Mar 2016 17:31:46 +0000
> > Cc: 23009-done <at> debbugs.gnu.org
> >
> > We still might consider solving the flicker problem for "no-conversion".
> Honestly I don't understand the
> > behavior of the meta mode at all: it seems that for the purpose of
> read-char the meta-mode is completely
> > ignored? If so, would it make sense to use
> set-keyboard-coding-system-internal, which doesn't appear to set
> > the meta-mode?
>
> Hmm... what does current-input-mode return on HTerm in "emacs -Q"?


(t nil 0 7)


>   I
> expect to see a non-nil, non-t value in the 3rd element of its return
> value.  If that's so, then testing that value for identity with the
> one we want to pass to set-input-meta-mode, and avoiding the latter
> call if the mode is already what we want, might avoid the flickering.
>
>
Yes, that's already the case (set-input-meta-mode doesn't reinitialize the
terminal if the meta mode doesn't change), and it's why I use latin-1
instead of no-conversion. With latin-1, a single mouse click results in 8
invocations of (set-input-meta-mode 8) (two mouse events with two
coordinates each, and a set and reset per coordinate). With no-conversion,
the same click results in four sequences of (set-input-meta-mode t)
(set-input-meta-mode
8), which causes the flicker.

[Message part 2 (text/html, inline)]

Message #40 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, Kenichi Handa <handa <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sun, 27 Mar 2016 18:21:10 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 26 Mar 2016 22:26:17 +0000
> Cc: 23009 <at> debbugs.gnu.org
> 
>  Hmm... what does current-input-mode return on HTerm in "emacs -Q"?
> 
> (t nil 0 7)
> 
>  I
>  expect to see a non-nil, non-t value in the 3rd element of its return
>  value. If that's so, then testing that value for identity with the
>  one we want to pass to set-input-meta-mode, and avoiding the latter
>  call if the mode is already what we want, might avoid the flickering.
> 
> Yes, that's already the case (set-input-meta-mode doesn't reinitialize the terminal if the meta mode doesn't
> change), and it's why I use latin-1 instead of no-conversion. With latin-1, a single mouse click results in 8
> invocations of (set-input-meta-mode 8) (two mouse events with two coordinates each, and a set and reset
> per coordinate). With no-conversion, the same click results in four sequences of (set-input-meta-mode t)
> (set-input-meta-mode 8), which causes the flicker.

Then I guess I'm confused about the reason for (set-input-meta-mode t)
in the case of no-conversion -- don't we want Emacs to pass the 8th
bit through without interpreting it?  Perhaps Handa-san could comment
on this, as I'm otherwise inclined to add raw-text to the list of the
coding-system types that want a non-nil, non-t value to be passed to
set-input-meta-mode.

Message #43 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 02 Apr 2016 12:43:13 +0300

> Date: Sun, 27 Mar 2016 18:21:10 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 23009 <at> debbugs.gnu.org
> 
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 26 Mar 2016 22:26:17 +0000
> > Cc: 23009 <at> debbugs.gnu.org
> > 
> >  Hmm... what does current-input-mode return on HTerm in "emacs -Q"?
> > 
> > (t nil 0 7)
> > 
> >  I
> >  expect to see a non-nil, non-t value in the 3rd element of its return
> >  value. If that's so, then testing that value for identity with the
> >  one we want to pass to set-input-meta-mode, and avoiding the latter
> >  call if the mode is already what we want, might avoid the flickering.
> > 
> > Yes, that's already the case (set-input-meta-mode doesn't reinitialize the terminal if the meta mode doesn't
> > change), and it's why I use latin-1 instead of no-conversion. With latin-1, a single mouse click results in 8
> > invocations of (set-input-meta-mode 8) (two mouse events with two coordinates each, and a set and reset
> > per coordinate). With no-conversion, the same click results in four sequences of (set-input-meta-mode t)
> > (set-input-meta-mode 8), which causes the flicker.
> 
> Then I guess I'm confused about the reason for (set-input-meta-mode t)
> in the case of no-conversion -- don't we want Emacs to pass the 8th
> bit through without interpreting it?  Perhaps Handa-san could comment
> on this, as I'm otherwise inclined to add raw-text to the list of the
> coding-system types that want a non-nil, non-t value to be passed to
> set-input-meta-mode.

Ping!

Philipp, can you try adding raw-text to that list, and see if the
result works correctly?

Message #46 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Kenichi Handa <handa <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 02 Apr 2016 19:10:45 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 2. Apr. 2016 um 11:43 Uhr:

> > Date: Sun, 27 Mar 2016 18:21:10 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 23009 <at> debbugs.gnu.org
> >
> > > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > > Date: Sat, 26 Mar 2016 22:26:17 +0000
> > > Cc: 23009 <at> debbugs.gnu.org
> > >
> > >  Hmm... what does current-input-mode return on HTerm in "emacs -Q"?
> > >
> > > (t nil 0 7)
> > >
> > >  I
> > >  expect to see a non-nil, non-t value in the 3rd element of its return
> > >  value. If that's so, then testing that value for identity with the
> > >  one we want to pass to set-input-meta-mode, and avoiding the latter
> > >  call if the mode is already what we want, might avoid the flickering.
> > >
> > > Yes, that's already the case (set-input-meta-mode doesn't reinitialize
> the terminal if the meta mode doesn't
> > > change), and it's why I use latin-1 instead of no-conversion. With
> latin-1, a single mouse click results in 8
> > > invocations of (set-input-meta-mode 8) (two mouse events with two
> coordinates each, and a set and reset
> > > per coordinate). With no-conversion, the same click results in four
> sequences of (set-input-meta-mode t)
> > > (set-input-meta-mode 8), which causes the flicker.
> >
> > Then I guess I'm confused about the reason for (set-input-meta-mode t)
> > in the case of no-conversion -- don't we want Emacs to pass the 8th
> > bit through without interpreting it?  Perhaps Handa-san could comment
> > on this, as I'm otherwise inclined to add raw-text to the list of the
> > coding-system types that want a non-nil, non-t value to be passed to
> > set-input-meta-mode.
>
> Ping!
>
> Philipp, can you try adding raw-text to that list, and see if the
> result works correctly?
>

Yes, it works (unsurprisingly), I've attached a patch.

[Message part 2 (text/html, inline)]

[0002-Simplify-8-bit-character-handling-for-raw-text.patch (application/octet-stream, attachment)]

Message #49 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: handa <at> gnu.org, 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 02 Apr 2016 22:53:14 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 02 Apr 2016 19:10:45 +0000
> Cc: 23009 <at> debbugs.gnu.org
> 
>  Ping!
> 
>  Philipp, can you try adding raw-text to that list, and see if the
>  result works correctly?
> 
> Yes, it works (unsurprisingly), I've attached a patch. 

Thanks.  Let's wait for a few more days, to let Handa-san an
opportunity to comment on that.

Message #52 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Fri, 08 Apr 2016 11:24:39 +0300

> Date: Sat, 02 Apr 2016 22:53:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 23009 <at> debbugs.gnu.org
> 
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 02 Apr 2016 19:10:45 +0000
> > Cc: 23009 <at> debbugs.gnu.org
> > 
> >  Ping!
> > 
> >  Philipp, can you try adding raw-text to that list, and see if the
> >  result works correctly?
> > 
> > Yes, it works (unsurprisingly), I've attached a patch. 
> 
> Thanks.  Let's wait for a few more days, to let Handa-san an
> opportunity to comment on that.

Forgot to CC him.  Any comments?

Message #55 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: p.stephani2 <at> gmail.com
Cc: 23009 <at> debbugs.gnu.org, Kenichi Handa <handa <at> gnu.org>
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 16 Apr 2016 12:57:25 +0300

> Date: Sat, 02 Apr 2016 22:53:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 23009 <at> debbugs.gnu.org
> 
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 02 Apr 2016 19:10:45 +0000
> > Cc: 23009 <at> debbugs.gnu.org
> > 
> >  Ping!
> > 
> >  Philipp, can you try adding raw-text to that list, and see if the
> >  result works correctly?
> > 
> > Yes, it works (unsurprisingly), I've attached a patch. 
> 
> Thanks.  Let's wait for a few more days, to let Handa-san an
> opportunity to comment on that.

No further comments, so I pushed this to the emacs-25 branch.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.