GNU bug report logs - #56854
28.1; Codes generated from focus events being sent to buffers.

Previous Next

Full log

View this message in rfc822 format

From: "M. Page-Lieberman" <mateus.justino <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andreas Schwab <schwab <at> linux-m68k.org>, 56854 <at> debbugs.gnu.org
Subject: bug#56854: 28.1; Codes generated from focus events being sent to buffers.
Date: Tue, 2 Aug 2022 13:13:28 -0400

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

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 <at> gnus.org> wrote:

> Andreas Schwab <schwab <at> 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.
>
>

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

[image.png (image/png, inline)]

Previous Next

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