Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stephen Berman <steve@ims.uni-stuttgart.de>]

Ralf Fassel <ralfixx@gmx.de> writes:

> * "Robert Marshall" <robert@chezmarshall.freeserve.co.uk>
> | I'm not sure which other window managers allow a change of workspace
> | by use of (only) the keyboard -
> 
> fvwm does.  I'm not fluent in french, so I'm not sure I did understand
> what the original problem was, but when using emacs' menu-bar, I can
> pop-up a menu, then change the workspace via keyboard-shortcuts, and
> the menu stays posted on the new workspace while the emacs frame is
> gone.  The menu takes effect if I select some entry.
> 
> It seems to me that is a question of global grab vs. application
> grab.
> 
> Other programs seem to issue a global grab while posting the menu, so
> the keyboard shortcuts don't reach the window manager, and no Desktop
> switching takes place until the menu is unposted.

As another datapoint, I have observed a different but perhaps related
problem with Emacs (both 21.2 and 20.7) under KDE (2.2.2): when I
click on a menu bar label in Emacs and then press `Ctrl-TAB' (the
KDE keyboard shortcut to change the virtual desktop/workspace) while
the Emacs menu is displayed, the keyboard locks up.  I haven't been
able to replicate this behavior with other apps in KDE (they simply
block switching of the desktop, as described above).  On the other
hand, it seems similar to a known KDE bug and has a similar
workaround, i.e., clicking on the border of an active window (see
e.g. bugs.kde.org/db/29/29926.html).

--Steve Berman