When in emacs, regardless of current buffer or current mode, switching to a different application with alt-tab is very slow (about half to three quarters of a second is my guess). This is independent of the switched-to application. Switching to emacs or between any two other applications is instant.
This is sometimes extremely annoying.
Steps to Reproduce:
1. Start emacs
2. Focus on emacs
3. Have some other application open (to act as target when alt-tabbing)
4. Press alt-tab to switch away and then back to emacs (doesn't happen the first time)
5. Press alt-tab to switch away from emacs
6. Wait too long for a core 2 duo with too much RAM
7. See other app come to the fore
Expect switching to be instant, or to be dependent on target app, since that is the app that has to be redrawn. Expectation met when emacs is not the source app.
Also happens in emacs-22.2-r2.
Also happens when emacs started with --no-desktop --no-init-file --no-site-file
This has been happening for a while. I thought it was standard, but now I found out that it works well in Ubuntu as far as I can tell (emacs-snapshot).
Not pasting .gnu-emacs since it happens with --no-init-file
Excerpts from emerge --info:
Portage 2.2_rc1 (default-linux/x86/2006.1/desktop, gcc-4.2.4, glibc-2.7-r0, 2.6.25-gentoo-r4 i686)
System uname: Linux-2.6.25-gentoo-r4-i686-Intel-R-_Core-TM-2_CPU_4300_@_1.80GHz-with-glibc2.0
Timestamp of tree: Fri, 04 Jul 2008 11:15:02 +0000
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python: 2.4.4-r13, 2.5.2-r2
sys-devel/autoconf: 2.13, 2.62
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
CFLAGS="-O2 -march=native -mtune=native -msse3 -pipe"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=native -mtune=native -msse3 -pipe"
FEATURES="autoaddcvs ccache distlocks keepwork parallel-fetch preserve-libs sandbox sfperms splitdebug strict unmerge-orphans userfetch userpriv"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
What window manager are you using?
(In reply to comment #2)
> metacity 2.22.0
I use that one, too, though I have a stable system and only some parts of Gnome 2.22 installed. No problems here.
I cannot reproduce the problem here.
Gnome team: adding you to CC, any ideas about this?
More likely an X driver issue. Could you tell us what versions you have for :
and could you attach a copy of your Xorg.O.log and xorg.conf?
xorg-server 1.4.2 (although the log below says 188.8.131.52 is running. I haven't restarted X for a while)
That said, this has been an issue for a long time, so I doubt it depends on the current versions running.
Xorg.log and xorg.conf attached (bugzilla didn't like them pasted in here)
Created attachment 160048 [details]
Created attachment 160050 [details]
Would you mind restarting your X? Does it happen even with a fresh session or only after a while?
Created attachment 160057 [details]
Here's the new xorg.log. I rebooted the machine to load the new nvidia drivers (previous session wasn't using the same drivers as I reported).
Issue is still there on a new session.
Something that I didn't make specific previously: the problem happens only when switching away from emacs by using alt-tab; if I use the mouse, the switch is instant. I was reminded of this because since restarting, the keyboard behaviour is a bit strange. The repeat goes fast for the first 5 characters or so, and then slows down as if some buffer has been filled.
<ulm> dberkholz: any idea what could be the issue with bug 231169?
<Willikins> ulm: https://bugs.gentoo.org/231169
"app-editors/emacs-cvs-23.0.9999 slow to alt-tab away from";
Gentoo Linux, Applications; NEW; email@example.com:firstname.lastname@example.org
<ulm> dberkholz: remi suspected it to be a driver problem
<nightmorph> solution: emerge -C emacs && emerge vim :p
<dberkholz> ulm: i don't really support binary drivers. but worth checking
whether the reporter has compositing enabled in metacity, and
whether he can reproduce with x86-video-nv.
<ulm> dberkholz: o.k., i'll ask him. and add x11 to cc
- Can you reproduce the problem with x11-drivers/xf86-video-nv?
- Do you have compositing enabled in metacity?
Compositing is disabled
The problem is also there when using the nv driver (I hope I don't have to test that very often, it does ugly things to my second monitor, and leaves it unusable till I reboot).
Something else I noticed: switching with alt-tab while emacs is loading works fast; it is only when emacs is fully loaded that it starts behaving the way described here.
Also, if running emacs 22.2.92, doing fast alt-tabs semi-freezes the X client (mouse cursor still moves, but I can't switch to another program), till I do something like ctrl-alt-f2 and kill emacs. This does not happen with emacs-cvs.
Is this still an issue?
More possibly-useful information:
I tried to see what was going on with the slow down by running emacs under xlibtrace (http://www.kev.pulo.com.au/xlibtrace/), which is just a library that uses a LD_PRELOAD to step in between all calls to xlib and just outputs what is going on, but when run under trace, the slow alt-tabbing behaviour disappears.
Upgraded to app-editors/emacs-cvs-23.0.9999-r1 last weekend. Fixed! Thanks!
(In reply to comment #16)
> Upgraded to app-editors/emacs-cvs-23.0.9999-r1 last weekend. Fixed! Thanks!
Could you verify that the bug is gone in the pretest version, emacs-cvs-23.0.90 (upstream released it today)?
My celebration was premature. I had forgotten I had turned off 'Enable assistive technologies' in the Assistive Technologies Preferences a while back after reading this:
(not exactly that, but some other related emacs bug on the ubuntu tracker which I can't find now)
The preference change is only activated after restarting gnome (which is why I forgot about it)
Turning on 'Enable assistive technologies' and restarting gnome brings the problem back. I'll live without the assistive technologies, but the bug should probably remain open.
Finally I succeeded to reproduce this on a current ~x86 system:
1. Make sure gnome-extra/at-spi (1.26.0), gnome-extra/libgail-gnome (1.20.1),
and app-editors/emacs-cvs (23.0.92) are installed
2. Start a Gnome session
3. Make sure that "assistive technologies" are enabled (if not, enable them and
4. Open a terminal window
5. Start Emacs with "emacs-23 -Q --daemon"
6. Open an Emacs frame with "emacsclient-23 -n -c" and focus on it
7. Press Alt-TAB
At this point, the session freezes for about 30 seconds.
Forgot to mention, no binary Xorg driver here, but x11-drivers/xf86-video-intel. IMHO it's unlikely that this is a driver issue.
I had this issue as well, and disabling assistive technologies fixed the problem. If I can help bisect the issue, let me know. Here's relevant package versions for now:
(In reply to comment #21)
> I had this issue as well, and disabling assistive technologies fixed the
> problem. If I can help bisect the issue, let me know.
Any help with this problem is welcome.
The upstream bug report is here:
No progress here. Closing.