Edebug, with Elisp source in different frame - Edebug doesn't select the source window.

Edebug, with Elisp source in different frame - Edebug doesn't select the source window.

[Alan Mackenzie]

Hello, Emacs.

Before I submit a bug report for this, I wonder if I'm doing something
silly.

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?

Note that in a text terminal, F1 gets selected as expected.  (Normally I
run Emacs in a text terminal.)

Does anybody have any ideas why this is happening to me in a GUI
environment?  Do other people see the same?  Why has nobody else
submitted a bug report for this?  Anything else?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug, with Elisp source in different frame - Edebug doesn't select the source window.

[Alan Mackenzie]

Hello, Emacs.

On Wed, Oct 17, 2018 at 14:22:26 +0000, Alan Mackenzie wrote:
> Before I submit a bug report for this, I wonder if I'm doing something
> silly.

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

> Note that in a text terminal, F1 gets selected as expected.  (Normally I
> run Emacs in a text terminal.)

> Does anybody have any ideas why this is happening to me in a GUI
> environment?  Do other people see the same?  Why has nobody else
> submitted a bug report for this?  Anything else?

I've found the answer, I think.  Edebug is using select-window to select
the frame.  What select-window doesn't do is to shift the X-Window focus.
For that, one needs to call select-frame-set-input-focus, something which
the current incarnation of edebug fails to do.

My first experimentation with s-f-set-i-focus indicates this is the
problem.  I will come up with a patch.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug, with Elisp source in different frame - Edebug doesn't select the source window. [PATCH]

[Alan Mackenzie]

Hello, Emacs.

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?

> I've found the answer, I think.  Edebug is using select-window to select
> the frame.  What select-window doesn't do is to shift the X-Window focus.
> For that, one needs to call select-frame-set-input-focus, something which
> the current incarnation of edebug fails to do.

More precisely, the function to call is x-focus-frame.

> My first experimentation with s-f-set-i-focus indicates this is the
> problem.  I will come up with a patch.

Here is the first version of that patch.  Now, in X, when edebug is
entered, the focus is moved to edebug buffer's frame.  When edebug is
terminated, it is moved back to the original frame.

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

Comments?


diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index fb567c9cce..4d9850c7f6 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -2328,6 +2328,7 @@ edebug-default-enter
               (debugger edebug-debugger) ; only while edebug is active.
               (edebug-outside-debug-on-error debug-on-error)
               (edebug-outside-debug-on-quit debug-on-quit)
+              (outside-frame (selected-frame))
               ;; Binding these may not be the right thing to do.
               ;; We want to allow the global values to be changed.
               (debug-on-error (or debug-on-error edebug-on-error))
@@ -2338,7 +2339,9 @@ edebug-default-enter
                                                 edebug-initial-mode
                                                 edebug-execution-mode)
                       edebug-next-execution-mode nil)
-                (edebug-default-enter function args body))))
+                (edebug-default-enter function args body))
+            (if (frame-live-p outside-frame)
+                (x-focus-frame outside-frame))))
 
       (let* ((edebug-data (get function 'edebug))
              (edebug-def-mark (car edebug-data)) ; mark at def start
@@ -2647,6 +2650,7 @@ edebug--display-1
 	  (edebug-eval-display eval-result-list)
 	  ;; The evaluation list better not have deleted edebug-window-data.
 	  (select-window (car edebug-window-data))
+          (x-focus-frame (window-frame (selected-window)))
 	  (set-buffer edebug-buffer)
 
 	  (setq edebug-buffer-outside-point (point))


-- 
Alan Mackenzie (Nuremberg, Germany).

Should FOCUS_OUT_EVENT be ignored for the purposes of input-pending-p? [was: Edebug, with Elisp source in different frame...]

[Alan Mackenzie]

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

Re: Should FOCUS_OUT_EVENT be ignored for the purposes of input-pending-p? [was: Edebug, with Elisp source in different frame...]

[Stefan Monnier]

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

LGTM, thank you Alan,


        Stefan