bug#56854: 28.1; Codes generated from focus events being sent to buffers.

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[M. Page-Lieberman]

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

--text follows this line--
[O] for out (exited) and [I] for in (entered) for Emacs windows focus
events are sent to buffers for the functions registered to the
focus-change-function events, AFAICT, and the frame-focus-state maps to
those codes (t -> [I], nil -> [O]).

In order to reproduce this, one needs to simply do C-u, wait for it to
appear in the mini buffer, and then switch to another frame. The code
"[ O-" will appear in the mini buffer. Upon returning focus to the frame,
the "[ O-" will be replaced by [ I-" in the minibuffer.

This would not be such a problem, if it were not for these codes being
thrown into the _main_ buffer when in LFE major mode ("[O [I [O [I [[O [I
[O]]] I [O [I]]]]]]") and switching back and forth among different Emacs
frames and different system app windows. I communicated to Robert
Virding (the creator and maintainer of LFE mode), but it was unclear to
me if he saw this message. Regardless, I told him that I would seek
assistance from the larger Emacs community on this issue, since it too
occurs in the minibuffer regardless of major modes. It can be replicated
for example in at least both List Interaction ElDoc mode and Text mode.

This behavior of event codes being sent to the minibuffer once C-u is
typed and frames lose focus was first detected in macOS' Terminal app
when connecting to a Raspberry Pi OS instance of Emacs over ssh, then a
local instance of Emacs running in the Terminal app on macOs, and then
finally also replicated on the Windows Console app.

The behavior does not occur when running Emacs in graphical mode.

In GNU Emacs 28.1 (build 1, x86_64-apple-darwin15.6.0, NS appkit-1404.47
Version 10.11.6 (Build 15G22010))
 of 2022-05-11 built on builder10-11.lan
System Description:  Mac OS X 10.11.6

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules
 CFLAGS=-DNSTextAlignmentRight=NSRightTextAlignment'

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

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
  global-eldoc-mode: t
  show-paren-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
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: 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 rfc6068 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 seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils term/xterm xterm byte-opt gv
bytecomp byte-compile cconv iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 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 emoji-zwj 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 55267 10759)
 (symbols 48 6667 1)
 (strings 32 18265 1947)
 (string-bytes 1 597801)
 (vectors 16 11475)
 (vector-slots 8 136249 7693)
 (floats 8 24 245)
 (intervals 56 251 0)
 (buffers 992 11))

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

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[Eli Zaretskii]

> From: "M. Page-Lieberman" <mateus.justino@gmail.com>
> Date: Sun, 31 Jul 2022 02:43:31 -0400
> 
> [O] for out (exited) and [I] for in (entered) for Emacs windows focus
> events are sent to buffers for the functions registered to the
> focus-change-function events, AFAICT, and the frame-focus-state maps to
> those codes (t -> [I], nil -> [O]).
> 
> In order to reproduce this, one needs to simply do C-u, wait for it to
> appear in the mini buffer, and then switch to another frame. The code
> "[ O-" will appear in the mini buffer. Upon returning focus to the frame,
> the "[ O-" will be replaced by [ I-" in the minibuffer.

Does this mean your terminal emulator doesn't support focus-in and
focus-out notifications?  Which terminal emulator is that and what is
its version?

Emacs enables this on xterm on the assumption that versions of xterm
that don't support this functionality simply ignore the sequences.

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[Andreas Schwab]

On Jul 31 2022, Eli Zaretskii wrote:

> Does this mean your terminal emulator doesn't support focus-in and
> focus-out notifications?

No, it's the other way round: since the terminal supports these events,
it generates the associated sequences.  But if Emacs is currently not
prepared to apply the input decode map (eg. while inside read-char) the
characters will be interpreted as normal keyboard input.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[Lars Ingebrigtsen]

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

Andreas Schwab <schwab@linux-m68k.org> writes:

> No, it's the other way round: since the terminal supports these events,
> it generates the associated sequences.  But if Emacs is currently not
> prepared to apply the input decode map (eg. while inside read-char) the
> characters will be interpreted as normal keyboard input.

Yup.  I can reproduce the behaviour in Ubuntu Terminal too, for
instance.  Recipe:

emacs -Q -nw
C-u

wait a bit, and then select a different application:


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

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



I thought there was another bug report open about this, but I can't find
it now.

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[M. Page-Lieberman]

[-- Attachment #1.1: Type: text/plain, Size: 2297 bytes --]

Well, if there's another bug report about it, then that leaves me hopeful,
and I'd like to peer into the discussion, as I searched and tried to find
any knowledge of this online before submitting the issue but struck out.

The fact that this seems to be universal behavior and so easy to reproduce
- yet also only found so far in the minibuffer through one key chord -
suggests that it might be easy to hunt down and fix, but at the same time,
is more so of a very low priority curiosity than an operationally
deleterious bug.

Attached in a screenshot, however, is why I find the issue troubling. When
in LFE (Lisp Flavored Erlang) major mode, I cannot task switch back and
forth without inserting a sequence of nested [O] [I] pairs into LFE code,
which in turn have to constantly be deleted.

I know there's an error that is reported when lfe-mode starts up, which
might wind up allowing this to happen somehow, but my sense is that it's
better to try to determine what glitch is shared between an lfe-mode main
buffer and the the universal (major mode agnostic) minibuffer.

I couldn't find anything that might be causing this in the lfe-mode Elisp
code, but I'm clueless when it comes to Emacs' Elisp library.

In a day or so, I'll get around to spinning up a new installation of
Raspberry Pi OS (not a headless installation with no graphical environment)
and attach a keyboard and a monitor to the RPi it to see if the behavior
can be reproduced in that OS' terminal emulators for LFE mode. I'll also
try to rope Robert Virding, the creator and maintainer of lfe-mode, into
this discussion too.

[image: image.png]

On Tue, Aug 2, 2022 at 6:53 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
> > No, it's the other way round: since the terminal supports these events,
> > it generates the associated sequences.  But if Emacs is currently not
> > prepared to apply the input decode map (eg. while inside read-char) the
> > characters will be interpreted as normal keyboard input.
>
> Yup.  I can reproduce the behaviour in Ubuntu Terminal too, for
> instance.  Recipe:
>
> emacs -Q -nw
> C-u
>
> wait a bit, and then select a different application:
>
>
>
> I thought there was another bug report open about this, but I can't find
> it now.
>
>

[-- Attachment #1.2: Type: text/html, Size: 2862 bytes --]

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

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

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

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I thought there was another bug report open about this, but I can't find
> it now.

bug#45834 perhaps?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

bug#56854: 28.1; Codes generated from focus events being sent to buffers.

[Lars Ingebrigtsen]

miha@kamnitnik.top writes:

>> I thought there was another bug report open about this, but I can't find
>> it now.
>
> bug#45834 perhaps?

Yes; thanks.  I've now merged the reports.