From: martin rudalics <rudalics@gmx.at>
To: Jonathan Ganc <jonganc@gmail.com>, 26104@debbugs.gnu.org
Subject: bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event
Date: Sat, 18 Mar 2017 09:19:04 +0100 [thread overview]
Message-ID: <58CCED78.8050904@gmx.at> (raw)
In-Reply-To: <e0208661-658c-928c-0c5e-5f472e21304a@gmail.com>
> That does fix the problem for yank-pop, but I don't think it's a good
> fix. For example, it let's someone use yank-pop without having used
> yank if they use handle-switch-frame before. Also, the same issue
> happens with other commands like dabbrev-expand, which relies on
> checking what the previous command was.
It wasn't meant to fix anything. I just wanted to know whether
bypassing this error would allow ‘yank-pop’ to proceed without further
problems.
> What is the purpose of executing `handle-switch-frame` at all? Maybe
> there's some way of excluding it from last-command. But again, I don't
> really understand x-windows well or why that command is being sent.
IIUC we don't "send" that command anywhere. We rather put it in the
event queue to tell ourselves that we are now in a safe and
"historically accurate" place to run Lisp, select that frame's selected
window and run some associated hooks. Maybe someone can tell us the
real purpose.
martin
next prev parent reply other threads:[~2017-03-18 8:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 3:25 bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event Jonathan Ganc
2017-03-17 7:19 ` martin rudalics
2017-03-18 1:04 ` Jonathan Ganc
2017-03-18 8:19 ` martin rudalics [this message]
2017-04-01 9:53 ` martin rudalics
2017-04-04 0:59 ` Jonathan Ganc
2017-04-05 6:58 ` martin rudalics
2017-04-07 3:56 ` Jonathan Ganc
2017-04-07 5:56 ` martin rudalics
2017-04-07 15:27 ` Jonathan Ganc
2017-04-08 8:59 ` martin rudalics
2017-04-08 22:42 ` Jonathan Ganc
2017-04-09 6:37 ` martin rudalics
2017-04-15 9:41 ` Jonathan Ganc
2017-04-15 14:50 ` martin rudalics
2017-04-15 15:11 ` Eli Zaretskii
2017-04-15 19:39 ` martin rudalics
2017-04-15 20:23 ` Jonathan Ganc
2017-04-16 7:15 ` martin rudalics
2017-04-15 20:33 ` Jonathan Ganc
2022-04-21 15:15 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58CCED78.8050904@gmx.at \
--to=rudalics@gmx.at \
--cc=26104@debbugs.gnu.org \
--cc=jonganc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).