bug#45834: 28.0.50; Mouse events in terminal emacs

bug#45834: 28.0.50; Mouse events in terminal emacs

[Brady]

Tested with emacs -Q -nw, in Terminal.app, with TERM=xterm-256color. The issue does not reproduce with TERM=rxvt.

If I press "C-h k", and then switch to another application, then this is registered as "ESC [ I-", and then upon switching back, as "ESC [ O-". I think this is about mouse events, in and out, or "I" and "O".

I think since I actually have M-[ bound to resize windows (without -Q), then this allows I and O to be passed to emacs and inserted as text, or for more strange behavior in other modes like evil or magit.

I'm not sure if this is considered an emacs problem, or if there is an idea for a workaround, besides perhaps unbinding M-[.

I just tested in a debian VM as well, with snapd's emacs 27.1, and the same issue occurs, C-h k, then M-TAB to switch to other application shows ESC [ I- in minibuffer. Similarly issue is seen with TERM=xterm-256color but not with rxvt.

Thank you,
-Brady

In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H2))
 of 2020-10-25 built on clay.local
Repository revision: 10ea719abcde4f2ee40e717eb846fe93f51d5d79
Repository branch: master
System Description:  Mac OS X 10.15.7

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS PDUMPER

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
  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 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 time-date
subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils cl-extra shortdoc seq help-fns radix-tree
help-mode easymenu cl-loaddefs cl-lib term/xterm xterm byte-opt gv
bytecomp byte-compile cconv tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win 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 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 kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 61436 5322)
 (symbols 48 6973 1)
 (strings 32 19556 966)
 (string-bytes 1 625828)
 (vectors 16 9903)
 (vector-slots 8 124271 9350)
 (floats 8 95 309)
 (intervals 56 351 0)
 (buffers 992 12))

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

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

Brady <bug-gnu-emacs_at_gnu.org@tangential.info> writes:

> I just tested in a debian VM as well, with snapd's emacs 27.1, and the
> same issue occurs, C-h k, then M-TAB to switch to other application
> shows ESC [ I- in minibuffer. Similarly issue is seen with
> TERM=xterm-256color but not with rxvt.

I can reproduce this with Emacs 28, too.

emacs -Q -nw
C-h k
*click in a different window*


[-- Attachment #2: Type: image/png, Size: 54606 bytes --]

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]


Anybody know what's going on here?

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

On January 19, 2021 8:38:07 AM GMT+02:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Brady <bug-gnu-emacs_at_gnu.org@tangential.info> writes:
> 
> > I just tested in a debian VM as well, with snapd's emacs 27.1, and
> the
> > same issue occurs, C-h k, then M-TAB to switch to other application
> > shows ESC [ I- in minibuffer. Similarly issue is seen with
> > TERM=xterm-256color but not with rxvt.
> 
> I can reproduce this with Emacs 28, too.
> 
> emacs -Q -nw
> C-h k
> *click in a different window*

I think it's the focus-in event that we somehow mishandle.  See xterm.el, search for "\e[I" (without the quotes).

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it's the focus-in event that we somehow mishandle.  See
> xterm.el, search for "\e[I" (without the quotes).

Instrumenting the  xterm-translate-focus-in/out functions shows that
they are being called, so that bit apparently works correctly?

However, if I say (read-event "foo: ") and then click on another window, 
I get the following return value, which...  I probably shouldn't?  Or
should I?

27[O

The reported test case is actually in

(read-key-sequence "foo: ")

and it won't actually return the \e[O, but will just append it to the
prompt.

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 45834@debbugs.gnu.org
> Date: Tue, 19 Jan 2021 16:22:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think it's the focus-in event that we somehow mishandle.  See
> > xterm.el, search for "\e[I" (without the quotes).
> 
> Instrumenting the  xterm-translate-focus-in/out functions shows that
> they are being called, so that bit apparently works correctly?
> 
> However, if I say (read-event "foo: ") and then click on another window, 
> I get the following return value, which...  I probably shouldn't?  Or
> should I?
> 
> 27[O
> 
> The reported test case is actually in
> 
> (read-key-sequence "foo: ")
> 
> and it won't actually return the \e[O, but will just append it to the
> prompt.

Does this work in Emacs 27?  If it does, I suspect one of the recent
changes in the input handling stuff...

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does this work in Emacs 27?  If it does, I suspect one of the recent
> changes in the input handling stuff...

No, Emacs 27 also has the same problem.  Emacs 26.1 does not, though.

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Does this work in Emacs 27?  If it does, I suspect one of the recent
>> changes in the input handling stuff...
>
> No, Emacs 27 also has the same problem.  Emacs 26.1 does not, though.

Poking at this a bit more -- the translation of these events apparently
relied on some magic in `read-event':

    ;; These translation functions actually call the focus handlers            
    ;; internally and return an empty sequence, causing us to go on to         
    ;; read the next event.                                                    
    (define-key map "\e[I" #'xterm-translate-focus-in)

;; By returning an empty key sequence, these two functions perform the         
;; moral equivalent of the kind of transparent event processing done           
;; by read-event's handling of special-event-map, but inside                   
;; read-key-sequence (which can recognize multi-character terminal             
;; notifications) instead of read-event (which can't).                         

(defun xterm-translate-focus-in (_prompt)
  (setf (terminal-parameter nil 'tty-focus-state) 'focused)
  (funcall after-focus-change-function)
  [])

This works in Emacs 26.1, but not Emacs 27.1.  I've stared at the
changes in read_key_sequence, but nothing seemed immediately suspicious
here... 

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 11:34:04 +0200
> 
> Poking at this a bit more -- the translation of these events apparently
> relied on some magic in `read-event':
> 
>     ;; These translation functions actually call the focus handlers            
>     ;; internally and return an empty sequence, causing us to go on to         
>     ;; read the next event.                                                    
>     (define-key map "\e[I" #'xterm-translate-focus-in)
> 
> ;; By returning an empty key sequence, these two functions perform the         
> ;; moral equivalent of the kind of transparent event processing done           
> ;; by read-event's handling of special-event-map, but inside                   
> ;; read-key-sequence (which can recognize multi-character terminal             
> ;; notifications) instead of read-event (which can't).                         
> 
> (defun xterm-translate-focus-in (_prompt)
>   (setf (terminal-parameter nil 'tty-focus-state) 'focused)
>   (funcall after-focus-change-function)
>   [])
> 
> This works in Emacs 26.1, but not Emacs 27.1.

Meaning what? that xterm-translate-focus-in is no longer being called?
But you said up-thread that the handler _is_ being called.

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Meaning what? that xterm-translate-focus-in is no longer being called?
> But you said up-thread that the handler _is_ being called.

It is called, but the event isn't translated to the [] null event any
more, so they "leak out" into the echo area (see screenshot in message
upstream).

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 11:54:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Meaning what? that xterm-translate-focus-in is no longer being called?
> > But you said up-thread that the handler _is_ being called.
> 
> It is called, but the event isn't translated to the [] null event any
> more, so they "leak out" into the echo area (see screenshot in message
> upstream).

It's not the echo-area that is the problem, it's the fact that "C-h k"
thinks it should describe the focus-in sequence, right?  If so, why is
that unexpected?  "C-h k" is supposed to describe the next input
event, right?  If we don't want it to describe the focus-in event, we
need to swallow it.

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It's not the echo-area that is the problem, it's the fact that "C-h k"
> thinks it should describe the focus-in sequence, right?

No, `C-h k' waits for the next real input event.

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 15:24:35 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's not the echo-area that is the problem, it's the fact that "C-h k"
> > thinks it should describe the focus-in sequence, right?
> 
> No, `C-h k' waits for the next real input event.

Which is the focus-in event, right?  Or what do you mean by "real
input event"?

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> No, `C-h k' waits for the next real input event.
>
> Which is the focus-in event, right?

No.

> Or what do you mean by "real input event"?

It waits for the user to hit a key, and Emacs meanwhile displays the
focus-in event stuff in the echo area.  Again, see the image in a previous
message that shows what it looks like after hitting `C-h k' and then
choosing a different application.

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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> Date: Wed, 08 Sep 2021 16:28:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 45834@debbugs.gnu.org
> 
> > No, `C-h k' waits for the next real input event.
> 
> Which is the focus-in event, right?  Or what do you mean by "real
> input event"?

Actually, there could be one more way for us to get that weird echo:
if Emacs thought that "ESC [ I" was a prefix key.  See that dash after
the sequence? that's what Emacs displays after key-echo when it
received a partial sequence, like if you type "C-x" and wait.  So
perhaps somehow Emacs thinks these focus-in events are prefix,
i.e. incomplete key sequence.

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, there could be one more way for us to get that weird echo:
> if Emacs thought that "ESC [ I" was a prefix key.  See that dash after
> the sequence? that's what Emacs displays after key-echo when it
> received a partial sequence, like if you type "C-x" and wait.  So
> perhaps somehow Emacs thinks these focus-in events are prefix,
> i.e. incomplete key sequence.

Yes, that sounds likely.  And....  if I `C-k h C-x' and then lose focus
and get it and then `a' and then lose and get focus and then `C-g', I
get:

C-x a C-g (translated from C-x M-[ O M-[ I a M-[ O M-[ I C-g) is undefined


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

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 15:41:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Actually, there could be one more way for us to get that weird echo:
> > if Emacs thought that "ESC [ I" was a prefix key.  See that dash after
> > the sequence? that's what Emacs displays after key-echo when it
> > received a partial sequence, like if you type "C-x" and wait.  So
> > perhaps somehow Emacs thinks these focus-in events are prefix,
> > i.e. incomplete key sequence.
> 
> Yes, that sounds likely.  And....  if I `C-k h C-x' and then lose focus
> and get it and then `a' and then lose and get focus and then `C-g', I
> get:
> 
> C-x a C-g (translated from C-x M-[ O M-[ I a M-[ O M-[ I C-g) is undefined

So somehow what we do in xterm-translate-focus-in causes Emacs to
interpret the sequence as an incomplete one.

Stefan, any ideas how that could happen?

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

I was wrong about this being a regression since Emacs 26 (sort of) --
since enabling focus-in things in xterm.el, this apparently has been the
way it's worked.  Emacs 26 doesn't do the focus tracking.

So `xterm-translate-focus-in' does the correct thing in the normal
command loop, but not quite when doing a read_key_sequence?  I mean,
what it's doing is better than what it'd otherwise do -- then `C-h k' +
focus out would read the first ESC and then "[O" would be inserted into
the buffer.

Which is indeed what happens if you say (read-event "foo") and then
change focus.

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

bug#45834: 28.0.50; Mouse events in terminal emacs

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

>> Yes, that sounds likely.  And....  if I `C-k h C-x' and then lose focus
>> and get it and then `a' and then lose and get focus and then `C-g', I
>> get:
>> 
>> C-x a C-g (translated from C-x M-[ O M-[ I a M-[ O M-[ I C-g) is undefined

Which part of this do you consider wrong?

> So somehow what we do in xterm-translate-focus-in causes Emacs to
> interpret the sequence as an incomplete one.

AFAIK, `C-x` is incomplete and so it `C-x a`, so I don't e anything
wrong in what is described above.


        Stefan

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 11:49:12 -0400
> 
> > So somehow what we do in xterm-translate-focus-in causes Emacs to
> > interpret the sequence as an incomplete one.
> 
> AFAIK, `C-x` is incomplete and so it `C-x a`, so I don't e anything
> wrong in what is described above.

I meant the original input: "ESC [ I"  This should be a complete key
sequence, given the following:

    (define-key map "\e[I" #'xterm-translate-focus-in)

But for some reason, "C-h k" thinks it's an incomplete key sequence,
because "C-h k" followed by a click on a different frame displays
"ESC [ I-" (note the dash).  Do you understand why this happens?

bug#45834: 28.0.50; Mouse events in terminal emacs

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

Eli wrote:
> I meant the original input: "ESC [ I"  This should be a complete key
> sequence, given the following:
>
>     (define-key map "\e[I" #'xterm-translate-focus-in)

`xterm-translate-focus-in` works at the level of keysequence remapping,
so "ESC [ I" is indeed a complete sequence but *for a remapping* and
it's remapped to the empty keysequence, which is not a complete keysequence.

In the sense of `C-h k`, "\e[I" is not bound to `xterm-translate-focus-in`.

AFAIK we don't currently have a command to query which key-remapping
happened for a given sequence of events, IOW, there is no equivalent to
`C-h k` that could tell the user that "\e[I" is "bound" to
`xterm-translate-focus-in`.

The closest that we have is that `C-h k` will tell the users both the
remapped keysequence and the original ("untranslated") keysequence.

> But for some reason, "C-h k" thinks it's an incomplete key sequence,
> because "C-h k" followed by a click on a different frame displays
> "ESC [ I-" (note the dash).  Do you understand why this happens?

Yes because "ESC [ I" is not a sequence of events that is sufficient to
successfully find a command bound to it in the normal keymaps (global
map, local map, minor mode maps, ...).  It's only bound in the
key-remapping maps, which are handled at another level (e.g.  when the
users hit `C-h k mouse-1` in an xterm, they are told which command
`mouse-1` runs rather than which function was used to remap the byte
sequence into the `mouse-1` event).

Lars wrote:
> It's not so much wrong as just pretty confusing.  That is, the original
> complaint is that saying `C-h k' and then focusing on some other app
> will leave Emacs saying "Describe the following ...: ESC [ O -", which
> wasn't the case in Emacs 26 (because we hadn't enabled mouse-in/out in
> xterm.el).

Indeed, the echoed keys are poor here.  I don't know why we have that
here: when I bind `f6` to a prefix keymap and I hit `f6` in xterm, I see
`f6-` in the echo area rather than `M-[ 1 7~-`, so there's something odd
going on, but AFAICT the problem is "cosmetic" in the sense that it only
affects the echoed keys.

I thought the bug report here was about a problem beyond the set of keys
that were echoed.


        Stefan

bug#45834: 28.0.50; Mouse events in terminal emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  45834@debbugs.gnu.org
> Date: Wed, 08 Sep 2021 22:22:48 -0400
> 
> Eli wrote:
> > I meant the original input: "ESC [ I"  This should be a complete key
> > sequence, given the following:
> >
> >     (define-key map "\e[I" #'xterm-translate-focus-in)
> 
> `xterm-translate-focus-in` works at the level of keysequence remapping,
> so "ESC [ I" is indeed a complete sequence but *for a remapping* and
> it's remapped to the empty keysequence, which is not a complete keysequence.
> 
> In the sense of `C-h k`, "\e[I" is not bound to `xterm-translate-focus-in`.
> 
> AFAIK we don't currently have a command to query which key-remapping
> happened for a given sequence of events, IOW, there is no equivalent to
> `C-h k` that could tell the user that "\e[I" is "bound" to
> `xterm-translate-focus-in`.
> 
> The closest that we have is that `C-h k` will tell the users both the
> remapped keysequence and the original ("untranslated") keysequence.

So you are basically saying that this stuff works as intended, and the
key-echo should be considered a "feature", or at worst a harmless
misfeature?

bug#45834: 28.0.50; Mouse events in terminal emacs

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

> So you are basically saying that this stuff works as intended, and the
> key-echo should be considered a "feature", or at worst a harmless
> misfeature?

I would not consider it a feature, but other than that, yes pretty much:
the key-echo part is clearly a bug (we normally display translated key
sequences rather than untranslated ones), but it doesn't cause any
further misbehavior as far a I can tell.


        Stefan

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed, the echoed keys are poor here.  I don't know why we have that
> here: when I bind `f6` to a prefix keymap and I hit `f6` in xterm, I see
> `f6-` in the echo area rather than `M-[ 1 7~-`, so there's something odd
> going on, but AFAICT the problem is "cosmetic" in the sense that it only
> affects the echoed keys.
>
> I thought the bug report here was about a problem beyond the set of keys
> that were echoed.

My reading is that this is purely about the confusing cosmetics:

  If I press "C-h k", and then switch to another application, then this is
  registered as "ESC [ I-"

Note the "-" at the end.  But perhaps Brady can clarify.

So this is a very minor issue, but it's just...  odd.

And it would perhaps be cool if Emacs had a mechanism to make events
like this "go away" more completely than we currently have, but that's
perhaps not feasible (since we do bind them to functions and stuff).

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

bug#45834: 28.0.50; Mouse events in terminal emacs

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

> And it would perhaps be cool if Emacs had a mechanism to make events
> like this "go away" more completely than we currently have, but that's
> perhaps not feasible (since we do bind them to functions and stuff).

I think we have the machinery in place to "make it go away".
There's a bug in it that makes it fail to do it job in this
specific circumstance.


        Stefan

bug#45834: 28.0.50; Mouse events in terminal emacs

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> C-x a C-g (translated from C-x M-[ O M-[ I a M-[ O M-[ I C-g) is undefined
>
> Which part of this do you consider wrong?
>
>> So somehow what we do in xterm-translate-focus-in causes Emacs to
>> interpret the sequence as an incomplete one.
>
> AFAIK, `C-x` is incomplete and so it `C-x a`, so I don't e anything
> wrong in what is described above.

It's not so much wrong as just pretty confusing.  That is, the original
complaint is that saying `C-h k' and then focusing on some other app
will leave Emacs saying "Describe the following ...: ESC [ O -", which
wasn't the case in Emacs 26 (because we hadn't enabled mouse-in/out in
xterm.el).

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