auto-raise-mode and auto-lower-mode

auto-raise-mode and auto-lower-mode

[Chong Yidong]

AFAICT, these don't work on modern window managers, right?  I'm going to
remove them from the Emacs manual.  Any opinion about marking them as
obsolete?

Re: auto-raise-mode and auto-lower-mode

[martin rudalics]

 > AFAICT, these don't work on modern window managers, right?  I'm going to
 > remove them from the Emacs manual.  Any opinion about marking them as
 > obsolete?

What about `minibuffer-auto-raise'?

martin

Re: auto-raise-mode and auto-lower-mode

[Štěpán Němec]

On Sun, 27 Nov 2011 08:17:55 +0100
Chong Yidong wrote:

> AFAICT, these don't work on modern window managers, right?  I'm going to
> remove them from the Emacs manual.  Any opinion about marking them as
> obsolete?

How is `auto-raise-mode' different from `raise-frame'? IOW, if you want
to obsolete the former, you might just as well obsolete the latter.

In any case, I thought `raise-frame' was supposed to work on Windows at
least, maybe also OS X and some other environments I don't use.

When `raise-frame' fails but the WM supports EWMH, the following has
worked for me:

(defadvice raise-frame (around wmctrl activate)
  (if (eq (window-system (ad-get-arg 0)) 'x)
      (x-send-client-message nil 0 (ad-get-arg 0)
                             "_NET_ACTIVE_WINDOW" 32 '(1))
    ad-do-it))

So ISTM fixing `raise-frame' would be a more appropriate solution.

-- 
Štěpán

Re: auto-raise-mode and auto-lower-mode

[Stefan Monnier]

> AFAICT, these don't work on modern window managers, right?

Really?

> I'm going to remove them from the Emacs manual.  Any opinion about
> marking them as obsolete?

I'd be happy to remove the C code that implements those features, but
I'd be even happier to replace it with Elisp code implementing that same
feature (especially if the Elisp code can be changed to do other
things: I've always wanted to try and make my minibuffer-only frame to
"auto-slide" like some panels do; on those tiny 1024x600 netbook
screens, vertical space has really high value).


        Stefan

Re: auto-raise-mode and auto-lower-mode

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> AFAICT, these don't work on modern window managers, right?
>
> Really?

After further testing, auto-raise-mode does work, but only if you enable
focus follows mouse _and_ disable auto raising in the window manager.
(There's no chance of making it work for focus follows click, because
the auto_raise frame parameter is only used from x_new_focus_frame.)
I'll update the docstring to make this clearer.

As for auto-lower-mode, it seems to interact badly with Metacity,
leaving the window permanently unraisable.  I have no idea what's going
on there.

Re: auto-raise-mode and auto-lower-mode

[Stephen J. Turnbull]

Chong Yidong writes:

 > As for auto-lower-mode, it seems to interact badly with Metacity,
 > leaving the window permanently unraisable.  I have no idea what's going
 > on there.

Metacity makes its own rules, or at the very least, assumes that
applications will conform to a very narrow interpretation of the
ICCCM.  In particular, it expects that applications will remember a
lot of things about window management state that the ICCCM allows the
window manager to enforce, and it ends up negotiating and even
executing *program* requests despite the fact that Metacity should
know that the *user* wants something else.  Maybe this is related.
Specifically, even though you may not be able to raise the window
using Metacity, perhaps it is possible to forcibly raise it from
elisp?

Since it's the standard WM in GNOME, I guess you have to cater
to it.

Does it matter whether the build is GTK-based or other-toolkit-based?