[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: bug emacs]

From: Stephen Berman
Subject: Re: address@hidden: bug emacs]
Date: 02 Apr 2002 13:09:07 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Ralf Fassel <address@hidden> writes:

> * "Robert Marshall" <address@hidden>
> | 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]