unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org
Subject: Should FOCUS_OUT_EVENT be ignored for the purposes of input-pending-p? [was: Edebug, with Elisp source in different frame...]
Date: Thu, 18 Oct 2018 14:26:28 +0000	[thread overview]
Message-ID: <20181018142628.GB3929@ACM> (raw)
In-Reply-To: <20181018110824.GA3929@ACM>

Hello, Emacs.

On Thu, Oct 18, 2018 at 11:08:24 +0000, Alan Mackenzie wrote:
> On Wed, Oct 17, 2018 at 16:22:53 +0000, Alan Mackenzie wrote:
> > On Wed, Oct 17, 2018 at 14:22:26 +0000, Alan Mackenzie wrote:

> > > In a GUI Emacs (26.1 or master), instrument a function for edebug with
> > > C-u C-M-x in frame F1.  From a different frame, F2, cause this function
> > > to be called, thus entering edebug.  F2 is still selected.  Surely edebug
> > > should have selected F1?

[ .... ]

> edebug-bounce-point has not been working either, but is more difficult
> to fix.  :-(

[ .... ]

I have modified edebug-bounce-point with calls to x-focus-frame.  This
failed to work, because there is a sit-for in the code.  keyboard.c
receives a FOCUS_OUT_EVENT, and thus input-pending-p returns t.  This
terminates the sit-for in edebug-bounce-point instantly.

This is somewhat similar to the situation in bug #10195.

I would like to filter out this event in readable_events (keyboard.c),
in the same way that FOCUS_IN_EVENT is filtered out.  This filtering
appears to be in the same spirit as this amendment:

    commit eaea02c71ae15d86bb83518796775b6c3c77b71e
    Author: Eli Zaretskii <eliz@gnu.org>
    Date:   Sat Jan 31 10:35:26 2015 +0200

        Fix while-no-input loops  (Bug#19547)

         src/keyboard.c (kbd_buffer_store_event_hold): Ignore FOCUS_OUT_EVENT
         and ICONIFY_EVENT for the purposes of breaking while-no-input
         loops.

I propose this change:


diff --git a/src/keyboard.c b/src/keyboard.c
index 8ea15d3c89..97482e1651 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -3344,7 +3344,8 @@ readable_events (int flags)
 #ifdef USE_TOOLKIT_SCROLL_BARS
 		    (flags & READABLE_EVENTS_FILTER_EVENTS) &&
 #endif
-		    event->kind == FOCUS_IN_EVENT)
+		    (event->kind == FOCUS_IN_EVENT
+                     || event->kind == FOCUS_OUT_EVENT))
 #ifdef USE_TOOLKIT_SCROLL_BARS
 		  && !((flags & READABLE_EVENTS_IGNORE_SQUEEZABLES)
 		       && (event->kind == SCROLL_BAR_CLICK_EVENT


This allows edebug-bounce-point to work in X, something it hasn't done
for a long time, if ever.  Before committing this, what sort of testing
do I need to do?  (I am restricted to GNU/Linux environments).

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2018-10-18 14:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17 14:22 Edebug, with Elisp source in different frame - Edebug doesn't select the source window Alan Mackenzie
2018-10-17 16:22 ` Alan Mackenzie
2018-10-18 11:08   ` Edebug, with Elisp source in different frame - Edebug doesn't select the source window. [PATCH] Alan Mackenzie
2018-10-18 14:26     ` Alan Mackenzie [this message]
2018-10-18 16:28       ` Should FOCUS_OUT_EVENT be ignored for the purposes of input-pending-p? [was: Edebug, with Elisp source in different frame...] Stefan Monnier

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=20181018142628.GB3929@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /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).