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