bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: M. Page-Lieberman
Subject: bug#56854: 28.1; Codes generated from focus events being sent to buffers.
Date: Tue, 2 Aug 2022 13:13:28 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]