display-buffer-reuse-frames in a tiling WM

display-buffer-reuse-frames in a tiling WM

[Alex Sparrow]

Hi all,

I have a question about the behaviour of display-buffer-reuse-frames
when using a tiling window manager (Xmonad in my case). The
documentation says:

"In addition, if the value of display-buffer-reuse-frames is non-nil, and
the buffer you want to switch to is already displayed in some frame,
Emacs will just raise that frame."

As I understand it, this just calls XRaiseWindow on the frame in
question. On XMonad (and presumably other tiling WMs) this has no
apparent effect when the frame is on a different workspace. This throws
me into confusion for a few seconds wondering why the buffer hasn't
opened. Is there any way to improve this behaviour? Even being able to
optionally set an URGENT hint on the window would be very useful I
think.

Thanks
Alex

RE: display-buffer-reuse-frames in a tiling WM

[Drew Adams]

> behaviour of display-buffer-reuse-frames
> when using a tiling window manager (Xmonad in my case). The
> documentation says:
> "In addition, if the value of display-buffer-reuse-frames is 
> non-nil, and the buffer you want to switch to is already
> displayed in some frame, Emacs will just raise that frame."
> 
> As I understand it, this just calls XRaiseWindow on the frame in
> question.

It sounds like that corresponds to the doc, at least.  (Note: I'm ignorant about
XRaiseWindow - just going by the name.)

> On XMonad (and presumably other tiling WMs) this has no
> apparent effect when the frame is on a different workspace.
>
> This throws me into confusion for a few seconds wondering
> why the buffer hasn't opened. Is there any way to improve
> this behaviour? Even being able to optionally set an URGENT
> hint on the window would be very useful I think.

It might (dunno) be appropriate to file an enhancement request, via `M-x
report-emacs-bug'.  That will bring this to the attention of the Emacs
developers - and possibly get you an informative answer.

Re: display-buffer-reuse-frames in a tiling WM

[Alex Sparrow]

Hi Drew,

Thanks for your thoughts. I appear to have found a solution to this
problem.

It seems that this issue was discussed in this thread on the emacs devel
list [1]. Apparently a window hint called _NET_ACTIVE_WINDOW needs to be
set in some WMs to "properly" raise a window. Unfortunately it seems
this functionality hasn't yet been added to Emacs.

However, I eventually found this thread [2], giving an elisp snippet to
set _NET_ACTIVE_WINDOW within raise-frame. In order to get Xmonad to
properly handle this message, I also had to enable the EWMH hooks as
described here [3].

I now find that selecting a previously opened buffer switches me to the
correct workspace as I wanted.

Cheers
Alex

[1] http://permalink.gmane.org/gmane.emacs.devel/61471
[2] http://permalink.gmane.org/gmane.emacs.help/81708
[3] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html

On Mon, Feb 06, 2012 at 09:16:30AM -0800, Drew Adams wrote:
>
> > behaviour of display-buffer-reuse-frames
> > when using a tiling window manager (Xmonad in my case). The
> > documentation says:
> > "In addition, if the value of display-buffer-reuse-frames is
> > non-nil, and the buffer you want to switch to is already
> > displayed in some frame, Emacs will just raise that frame."
> >
> > As I understand it, this just calls XRaiseWindow on the frame in
> > question.
>
> It sounds like that corresponds to the doc, at least.  (Note: I'm ignorant about
> XRaiseWindow - just going by the name.)
>
> > On XMonad (and presumably other tiling WMs) this has no
> > apparent effect when the frame is on a different workspace.
> >
> > This throws me into confusion for a few seconds wondering
> > why the buffer hasn't opened. Is there any way to improve
> > this behaviour? Even being able to optionally set an URGENT
> > hint on the window would be very useful I think.
>
> It might (dunno) be appropriate to file an enhancement request, via `M-x
> report-emacs-bug'.  That will bring this to the attention of the Emacs
> developers - and possibly get you an informative answer.
>