Raising the Emacs frame in response to a DBUS signal

Raising the Emacs frame in response to a DBUS signal

[Tassilo Horn]

Hi all,

GNU AUCTeX supports inverse search for the Evince PDF viewer, i.e., when
you're writing a LaTeX document with Emacs/AUCTeX and view the compiled
PDF using Evince, you can Ctrl-click in Evince and Emacs jumps to the
corresponding text in your LaTeX editing buffer.  For that purpose,
Emacs is registered to handle SyncSource DBUS signals issued by Evince.

Since recently (no clue when as I normally don't use Evince but the PDF
Tools Emacs PDF viewer) in Emacs 25, the Emacs frame is not raised
anymore when the AUCTeX function handling the SyncSource signal is
called, and the problem is that I don't know how to achieve that again.

`raise-frame' seems to raise the selected frame above other Emacs frames
of the same Emacs instance but not above other applications (like
Evince).  Here in Gnome 3.20, I get at least a notification "Emacs is
ready" which I can click to switch to Emacs.  But the user who reported
the problem uses XFCE where nothing seems to happen.  Or better, point
in Emacs jumps to the right position but he has to switch to Emacs
explicitly.

Then I found `x-focus-frame' which seems to do what I want.  A simple
test case like evaluating

  (progn
    (sleep-for 5)
    (x-focus-frame (selected-frame)))

in *scratch* and then switching to another application brings Emacs to
the front again when the 5 seconds have passed.  However, when I add the
very same `x-focus-frame' call to the end of the AUCTeX SyncSource DBUS
handler function, it seems to have no effect.  The function is run and
switches to the right LaTeX editing buffer and sets point, but Emacs
the Emacs frame is not raised.

That's the actual function:

  http://git.savannah.gnu.org/cgit/auctex.git/tree/tex.el#n1849

In some previous version of the function I've called `raise-frame' at
the end but eventually removed that call.  Sadly, I'm don't know anymore
why I did that.  Either because the frame was raised anyhow or because
it didn't raise.

I checked the ChangeLogs but couldn't find some change which looks
relevant.

Bye,
Tassilo

Re: Raising the Emacs frame in response to a DBUS signal

[cesar mena]

Tassilo Horn <tsdh@gnu.org> writes:

> Hi all,
>
> GNU AUCTeX supports inverse search for the Evince PDF viewer, i.e., when
> you're writing a LaTeX document with Emacs/AUCTeX and view the compiled
> PDF using Evince, you can Ctrl-click in Evince and Emacs jumps to the
> corresponding text in your LaTeX editing buffer.  For that purpose,
> Emacs is registered to handle SyncSource DBUS signals issued by Evince.
>
> Since recently (no clue when as I normally don't use Evince but the PDF
> Tools Emacs PDF viewer) in Emacs 25, the Emacs frame is not raised
> anymore when the AUCTeX function handling the SyncSource signal is
> called, and the problem is that I don't know how to achieve that again.
>
> `raise-frame' seems to raise the selected frame above other Emacs frames
> of the same Emacs instance but not above other applications (like
> Evince).  Here in Gnome 3.20, I get at least a notification "Emacs is
> ready" which I can click to switch to Emacs.  But the user who reported
> the problem uses XFCE where nothing seems to happen.  Or better, point
> in Emacs jumps to the right position but he has to switch to Emacs
> explicitly.
>
> Then I found `x-focus-frame' which seems to do what I want.  A simple
> test case like evaluating
>
>   (progn
>     (sleep-for 5)
>     (x-focus-frame (selected-frame)))
>
> in *scratch* and then switching to another application brings Emacs to
> the front again when the 5 seconds have passed.  However, when I add the
> very same `x-focus-frame' call to the end of the AUCTeX SyncSource DBUS
> handler function, it seems to have no effect.  The function is run and
> switches to the right LaTeX editing buffer and sets point, but Emacs
> the Emacs frame is not raised.
>
> That's the actual function:
>
>   http://git.savannah.gnu.org/cgit/auctex.git/tree/tex.el#n1849
>
> In some previous version of the function I've called `raise-frame' at
> the end but eventually removed that call.  Sadly, I'm don't know anymore
> why I did that.  Either because the frame was raised anyhow or because
> it didn't raise.
>
> I checked the ChangeLogs but couldn't find some change which looks
> relevant.
>
> Bye,
> Tassilo

hi,

see if the below advise works for you. it uses wmctrl to raise the
frame. there's an explanation in the gmane article linked in the comment.

   (defadvice raise-frame (after make-it-work (&optional frame) activate)
     "Work around some bug? in raise-frame/Emacs/GTK/Metacity/something.
      Katsumi Yamaoka <yamaoka@jpl.org> posted this in 
      http://article.gmane.org/gmane.emacs.devel:39702"
      (call-process
       "wmctrl" nil nil nil "-i" "-R"
       (frame-parameter (or frame (selected-frame)) 'outer-window-id)))

-cm

Re: Raising the Emacs frame in response to a DBUS signal

[Tassilo Horn]

cesar mena <cesar.mena@gmail.com> writes:

Hi Cesar,

> see if the below advise works for you.  it uses wmctrl to raise the
> frame.  there's an explanation in the gmane article linked in the
> comment.

Well, using wmctrl would most probably work but we can't really depend
on external programs which might not be installed anyway.

That said, the function used to work as intended for me on Gnome and
also for that other user on XFCE.  Of course, it might be that something
else lead to this problem, e.g., a change in X or GTK+.  But how can I
know?

What's not explainable to me is that evaluating

  (progn
    (sleep-for 5)
    (x-focus-frame (selected-frame)))

in *scratch* will bring emacs to the front after I've covered it with
other applications' windows, but when (x-focus-frame (selected-frame))
is called by the handler function that processes the DBUS signal from
Evince, it doesn't bring emacs to the front.

Oh, here's news.  If the AUCTeX handler function waits a second before
calling `x-focus-frame', it works again.

  ;; This works!
  (run-at-time 1 nil
    (lambda ()
      (x-focus-frame (selected-frame))))

Does anyone know what might be the problem?  Maybe some "focus stealing
policy" that prevents that an application is raised just a fraction of a
second after something has been clicked in another application?

Bye,
Tassilo

Re: Raising the Emacs frame in response to a DBUS signal

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Mon, 30 May 2016 13:53:51 +0200
> Cc: emacs-devel@gnu.org
> 
> What's not explainable to me is that evaluating
> 
>   (progn
>     (sleep-for 5)
>     (x-focus-frame (selected-frame)))
> 
> in *scratch* will bring emacs to the front after I've covered it with
> other applications' windows, but when (x-focus-frame (selected-frame))
> is called by the handler function that processes the DBUS signal from
> Evince, it doesn't bring emacs to the front.
> 
> Oh, here's news.  If the AUCTeX handler function waits a second before
> calling `x-focus-frame', it works again.
> 
>   ;; This works!
>   (run-at-time 1 nil
>     (lambda ()
>       (x-focus-frame (selected-frame))))
> 
> Does anyone know what might be the problem?  Maybe some "focus stealing
> policy" that prevents that an application is raised just a fraction of a
> second after something has been clicked in another application?

You are playing with window-manager policies and with the fact that a
request to raise a frame is not executed by it immediately.  AFAIR,
this was always a grey area, and I don't think Emacs can do anything
about this that would work portably.

Re: Raising the Emacs frame in response to a DBUS signal

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Does anyone know what might be the problem?  Maybe some "focus
>> stealing policy" that prevents that an application is raised just a
>> fraction of a second after something has been clicked in another
>> application?
>
> You are playing with window-manager policies and with the fact that a
> request to raise a frame is not executed by it immediately.  AFAIR,
> this was always a grey area, and I don't think Emacs can do anything
> about this that would work portably.

Ok, thanks for confirmation.  Then I'll work around this somehow.

Bye,
Tassilo