Re: [jonathan.the-seng1 <at> etud.univ-ubs.fr: bug emacs]
Stephen Berman <steve <at> ims.uni-stuttgart.de>
2002-04-02 11:09:07 GMT
Ralf Fassel <ralfixx <at> gmx.de> writes:
> * "Robert Marshall" <robert <at> 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).
(Continue reading)