gvim slow to respond

Bug #856779 reported by ChrisMague on 2011-09-22
144
This bug affects 25 people
Affects Status Importance Assigned to Milestone
vim (Fedora)
Fix Released
Medium
vim (Ubuntu)
Undecided
Rex Tsai
Oneiric
Undecided
Rex Tsai

Bug Description

[Impact]
The bug makes gvim windows unresponsive to keyboard events for seconds to minutes after a window is opened. It happens every time a window is opened. It's annoying and makes gvim very difficult to use.

Problem: Opening a window before forking causes problems for GTK.

[Development Fix]
using patch from upstream v7-3-315.
> Fork first, create the window in the child and report back to the
> parent process whether it worked. If successful the parent exits,
> if unsuccessful the child exits and the parent continues in the
> terminal. (Tim Starling)

[Stable Fix]
Retrieve upstream patch v7-3-315, a few minor changes to fit into current codebase.

[Test Case]
1. Open a gvim window
2. Focus window and press arrow keys immediately after opening
Broken Behavior: Arrow keys have no effect. Clicking around will move the cursor normally
Fixed Behavior: Arrow keys move cursor

[Regression Potential]
N/A.

[Original Report]
Opening up GVIM takes long time and edit commands such as moving are very slow.

strace shows lots of waiting:
poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}], 7, -1) = 1 ([{fd=5, revents=POLLIN}])
read(5, "\f\0\f\250E\0\340\5\0\0\25\0a\0\32\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 160
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}], 7, 0) = 0 (Timeout)
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{"5\30\4\0\226\16\340\5E\0\340\5a\0\24\2\225\4\5\0\227\16\340\5\226\16\340\5*\0\0\0"..., 8180}, {NULL, 0}, {"", 0}], 3) = 8180
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}], 7, -1) = 1 ([{fd=5, revents=POLLIN}])
read(5, "\f\0i\251E\0\340\5\\\0/\0\5\0\1\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 160
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}], 7, 0) = 0 (Timeout)
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{"5\30\4\0\230\16\340\5E\0\340\5\t\0\24\2\225\4\5\0\231\16\340\5\230\16\340\5*\0\0\0"..., 4440}, {NULL, 0}, {"", 0}], 3) = 4440
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(5, 0x11fa014, 4096) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}], 7, -1^C <unfinished ...>

fds are here

gvim 6138 maguec 0u CHR 136,0 0t0 3 /dev/pts/0
gvim 6138 maguec 1u CHR 136,0 0t0 3 /dev/pts/0
gvim 6138 maguec 2u CHR 136,0 0t0 3 /dev/pts/0
gvim 6138 maguec 3r FIFO 0,8 0t0 213734 pipe
gvim 6138 maguec 4w FIFO 0,8 0t0 213734 pipe
gvim 6138 maguec 5u unix 0x0000000000000000 0t0 213737 socket
gvim 6138 maguec 6u 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 7u unix 0x0000000000000000 0t0 212773 socket
gvim 6138 maguec 8u 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 9r FIFO 0,8 0t0 213743 pipe
gvim 6138 maguec 10w FIFO 0,8 0t0 213743 pipe
gvim 6138 maguec 11u unix 0x0000000000000000 0t0 213744 socket
gvim 6138 maguec 12u unix 0x0000000000000000 0t0 213745 socket
gvim 6138 maguec 13u 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 14u 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 15u unix 0x0000000000000000 0t0 212774 socket
gvim 6138 maguec 16u unix 0x0000000000000000 0t0 213752 socket
gvim 6138 maguec 17u 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 18r 0000 0,9 0 5107 anon_inode
gvim 6138 maguec 20u REG 8,6 12288 8478 /home/maguec/tmp/vim/%home%maguec%Code%oppy%bin%check_status.swp

ProblemType: BugDistroRelease: Ubuntu 11.10
Package: vim-gnome 2:7.3.154+hg~74503f6ee649-2ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
Date: Thu Sep 22 13:30:21 2011
ExecutablePath: /usr/bin/vim.gnomeInstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8SourcePackage: vim
UpgradeStatus: Upgraded to oneiric on 2011-09-02 (19 days ago)

Description of problem:
When opening a text file, gvim is very sluggish. It takes a while until key input is processed (actually in a kind of "burst mode") making it impossible to actually edit the loaded text in reasonable manner. In the meantime, the shell from which gvim had been started is filled with warnings:

(gvim:5333): IBUS-WARNING **: org.freedesktop.IBus.InputContext.ProcessKeyEvent: Timeout was reached

Version-Release number of selected component (if applicable):
vim-X11-7.3.107-1.fc15.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Start GNOME session.
2. Open file in gvim.
3. Move cursor and edit some text.

Actual results:
gvim is very sluggish. Key input accumulates until it gets processed after some time in a kind of burst.

Expected results:
gvim allows to edit the text in a fluent manner.

Additional info:
None.

Issue has disappeared for current "rawhide" - probably a now resolved problem in the GNOME infastructure as the version of vim-X11 has not changed in the meantime.

Fully updated F15 shows significant latencies of various actions within gvim, e.g. when opening the "Find and Replace..." dialog from the "Edit" menu:

(gvim:2821): IBUS-WARNING **: org.freedesktop.IBus.CreateInputContext: Timeout was reached
(gvim:2821): IBUS-CRITICAL **: _create_input_context: assertion `ibusimcontext->ibuscontext != NULL' failed
(gvim:2821): IBUS-WARNING **: org.freedesktop.IBus.CreateInputContext: Timeout was reached
(gvim:2821): IBUS-CRITICAL **: _create_input_context: assertion `ibusimcontext->ibuscontext != NULL' failed

Interestingly, when repeating said operation for the same instance of gvim, the dialog window appears immediately.

It should be added that it is impossible to navigate through or to edit a text. The program does not react to keyboard input.

I am trying search in GVIM and observe similar oddities:

How reproducible:
Always.

Steps to Reproduce:
1. Start terminal
2. gvim somefile
3. Press '/' for search start.

The following output in my terminal appears:

(gvim:9913): IBUS-WARNING **: org.freedesktop.IBus.InputContext.GetEngine: Časový limit vypršel

(gvim:9913): IBUS-WARNING **: org.freedesktop.IBus.InputContext.GetEngine: Časový limit vypršel

(gvim:9913): IBUS-WARNING **: org.freedesktop.IBus.CreateInputContext: Časový limit vypršel

(gvim:9913): IBUS-CRITICAL **: _create_input_context: assertion `ibusimcontext->ibuscontext != NULL' failed

It takes like 10 seconds before the search itself is possible.

but if launched as root (sudo gvim), there is not slowdown, but very responsive.

(In reply to comment #5)
Right, that is what I am seeing, too.

gvim is responsive, however, if launched from the Gnome 3 super-key application launcher. It's still non-responsive if launched from a terminal or Alt-F2

Why has this been marked as closed? It is most frustrating to use gvim with this responsiveness (rather lack of). It is NOT fixed in
vim-X11-7.3.138-1.fc15.x86_64

PLEASE RE-OPEN

I agree, this is not fixed. It becomes usable as soon as I press '/' but not before.

(In reply to comment #9)
Have you enabled updates-testing? The fact that gvim works on my own system now without problem when launched from the shell suggests that the culprit is actually some other component, probably some GNOME infrastructure package for which a more recent build is available in updates-testing.

(In reply to comment #10)
No, I don't have enabled updates-testing and I can't see there any GNOME package update which would help to solve this issue.

(In reply to comment #11)
As the original reporter of this issue, I recommend you to enable updates-testing and to try it out yourself when you cannot see which package might be responsible. It could be also useful to create a new user account in order to avoid interference with custom settings and to verify whether the issue persists in this case.

(In reply to comment #8)
Please retry for current F15: I have reinstalled from scratch with F15 repos "fedora" and "updates" being enabled but not "updates-testing".
Result: gvim behaves absolutely normal.

No go. Responsiveness is very slow until I press '/', then behavior is normally good.

After pressing the '/', I get the following message:

(gvim:4034): IBUS-WARNING **: Create input context failed: Timeout was reached.

I noticed that this problem appears just when GVIM forks from the terminal. If I run gvim with "-f" flag, i.e. no fork, it runs smoothly (but of course do not detach from terminal :/)

I have enabled 'update' and 'updates-testing' and is using ibus-1.3.99.20110419-5.fc15.i686 and vim-X11-7.3.138-1.fc15.i686.
It turns out that starting `gvim` from terminal behave quite differently in different desktop environments:

    gnome3 OK
    kde-4.6.4 slow
    xfce-4.8 slow
    enlightenment OK
    fluxbox OK
    openbox slow

This is really weird, or interesting.

Since gnome3 is the default desktop of fedora 15, maybe this bug was closed without noticing gvim not working well in other desktops.

Hope my finding may give some help.

(In reply to comment #16)
I am using Gnome 3 and it is slow, so I cannot confirm your observation.

I am using Fedora 15 with kde-4.6.3 and I can confirm this bug.

I'm using Fedora 15 with kde-4.6.3 and stilll can't reproduce this issue.
Lets check the exact library versions.
One of those with a slow gvim, please attach the output of:
ldd /usr/bin/gvim | cut -d ' ' -f 3| xargs rpm -qf| sort | uniq

atk-2.0.0-1.fc15.x86_64
cairo-1.10.2-3.fc15.x86_64
expat-2.0.1-11.fc15.x86_64
fontconfig-2.8.0-3.fc15.x86_64
freetype-2.4.4-4.fc15.x86_64
gdk-pixbuf2-2.23.3-2.fc15.x86_64
glib2-2.28.8-1.fc15.x86_64
glibc-2.14-4.x86_64
gpm-libs-1.20.6-16.fc15.x86_64
gtk2-2.24.4-2.fc15.x86_64
libacl-2.2.49-9.fc15.x86_64
libattr-2.4.44-7.fc15.x86_64
libgcc-4.6.0-9.fc15.x86_64
libICE-1.0.6-3.fc15.x86_64
libpng-1.2.44-3.fc15.x86_64
libselinux-2.0.99-4.fc15.x86_64
libSM-1.2.0-2.fc15.x86_64
libuuid-2.19.1-1.2.fc15.x86_64
libX11-1.4.3-1.fc15.x86_64
libXau-1.0.6-2.fc15.x86_64
libxcb-1.7-2.fc15.x86_64
libXcomposite-0.4.3-2.fc15.x86_64
libXcursor-1.1.11-3.fc15.x86_64
libXdamage-1.1.3-2.fc15.x86_64
libXext-1.2.0-2.fc15.x86_64
libXfixes-5.0-1.fc15.x86_64
libXi-1.4.3-1.fc15.x86_64
libXinerama-1.1.1-2.fc15.x86_64
libXrandr-1.3.1-2.fc15.x86_64
libXrender-0.9.6-2.fc15.x86_64
libXt-1.1.0-1.fc15.x86_64
ncurses-libs-5.8-2.20110319.fc15.x86_64
nss-softokn-freebl-3.12.10-2.fc15.x86_64
pango-1.28.4-1.fc15.x86_64
perl-libs-5.12.4-159.fc15.x86_64
pixman-0.20.2-2.fc15.x86_64
python-libs-2.7.1-7.fc15.x86_64
ruby-libs-1.8.7.334-1.fc15.x86_64
zlib-1.2.5-3.fc15.x86_64

[bpm]$ sudo ldd /usr/bin/gvim | cut -d ' ' -f 3| xargs rpm -qf| sort | uniq
atk-2.0.0-1.fc15.x86_64
cairo-1.10.2-3.fc15.x86_64
expat-2.0.1-11.fc15.x86_64
fontconfig-2.8.0-3.fc15.x86_64
freetype-2.4.4-4.fc15.x86_64
gdk-pixbuf2-2.23.3-2.fc15.x86_64
glib2-2.28.8-1.fc15.x86_64
glibc-2.14-4.x86_64
gpm-libs-1.20.6-16.fc15.x86_64
gtk2-2.24.4-2.fc15.x86_64
libacl-2.2.49-9.fc15.x86_64
libattr-2.4.44-7.fc15.x86_64
libgcc-4.6.0-9.fc15.x86_64
libICE-1.0.6-3.fc15.x86_64
libpng-1.2.44-3.fc15.x86_64
libselinux-2.0.99-4.fc15.x86_64
libSM-1.2.0-2.fc15.x86_64
libuuid-2.19.1-1.2.fc15.x86_64
libX11-1.4.3-1.fc15.x86_64
libXau-1.0.6-2.fc15.x86_64
libxcb-1.7-2.fc15.x86_64
libXcomposite-0.4.3-2.fc15.x86_64
libXcursor-1.1.11-3.fc15.x86_64
libXdamage-1.1.3-2.fc15.x86_64
libXext-1.2.0-2.fc15.x86_64
libXfixes-5.0-1.fc15.x86_64
libXi-1.4.3-1.fc15.x86_64
libXinerama-1.1.1-2.fc15.x86_64
libXrandr-1.3.1-2.fc15.x86_64
libXrender-0.9.6-2.fc15.x86_64
libXt-1.1.0-1.fc15.x86_64
ncurses-libs-5.8-2.20110319.fc15.x86_64
nss-softokn-freebl-3.12.10-2.fc15.x86_64
pango-1.28.4-1.fc15.x86_64
perl-libs-5.12.4-159.fc15.x86_64
pixman-0.20.2-2.fc15.x86_64
python-libs-2.7.1-7.fc15.x86_64
ruby-libs-1.8.7.334-1.fc15.x86_64
zlib-1.2.5-3.fc15.x86_64

atk-2.0.0-1.fc15.i686
cairo-1.10.2-3.fc15.i686
expat-2.0.1-11.fc15.i686
fontconfig-2.8.0-3.fc15.i686
freetype-2.4.4-4.fc15.i686
gdk-pixbuf2-2.23.3-2.fc15.i686
glib2-2.28.8-1.fc15.i686
glibc-2.14-4.i686
gpm-libs-1.20.6-16.fc15.i686
gtk2-2.24.4-2.fc15.i686
libacl-2.2.49-9.fc15.i686
libattr-2.4.44-7.fc15.i686
libgcc-4.6.0-10.fc15.i686
libICE-1.0.6-3.fc15.i686
libpng-1.2.44-3.fc15.i686
libselinux-2.0.99-4.fc15.i686
libSM-1.2.0-2.fc15.i686
libuuid-2.19.1-1.3.fc15.i686
libX11-1.4.3-1.fc15.i686
libXau-1.0.6-2.fc15.i686
libxcb-1.7-2.fc15.i686
libXcomposite-0.4.3-2.fc15.i686
libXcursor-1.1.11-3.fc15.i686
libXdamage-1.1.3-2.fc15.i686
libXext-1.2.0-2.fc15.i686
libXfixes-5.0-1.fc15.i686
libXi-1.4.3-1.fc15.i686
libXinerama-1.1.1-2.fc15.i686
libXrandr-1.3.1-2.fc15.i686
libXrender-0.9.6-2.fc15.i686
libXt-1.1.0-1.fc15.i686
ncurses-libs-5.8-2.20110319.fc15.i686
nss-softokn-freebl-3.12.10-2.fc15.i686
pango-1.28.4-1.fc15.i686
perl-libs-5.12.4-159.fc15.i686
pixman-0.20.2-2.fc15.i686
python-libs-2.7.1-7.fc15.i686
ruby-libs-1.8.7.334-1.fc15.i686
zlib-1.2.5-3.fc15.i686

ok, I have now the same libraries as the first poster, still no slowdown.
Must be something else...

$ ldd /usr/bin/gvim | cut -d ' ' -f 3| xargs rpm -qf| sort | uniq
atk-2.0.0-1.fc15.x86_64
cairo-1.10.2-3.fc15.x86_64
expat-2.0.1-11.fc15.x86_64
fontconfig-2.8.0-3.fc15.x86_64
freetype-2.4.4-4.fc15.x86_64
gdk-pixbuf2-2.23.3-2.fc15.x86_64
glibc-2.14-3.x86_64
glib2-2.28.8-1.fc15.x86_64
gpm-libs-1.20.6-16.fc15.x86_64
gtk2-2.24.4-2.fc15.x86_64
libacl-2.2.49-9.fc15.x86_64
libattr-2.4.44-7.fc15.x86_64
libgcc-4.6.0-9.fc15.x86_64
libICE-1.0.6-3.fc15.x86_64
libpng-1.2.44-3.fc15.x86_64
libselinux-2.0.99-4.fc15.x86_64
libSM-1.2.0-2.fc15.x86_64
libuuid-2.19.1-1.2.fc15.x86_64
libXau-1.0.6-2.fc15.x86_64
libxcb-1.7-2.fc15.x86_64
libXcomposite-0.4.3-2.fc15.x86_64
libXcursor-1.1.11-3.fc15.x86_64
libXdamage-1.1.3-2.fc15.x86_64
libXext-1.2.0-2.fc15.x86_64
libXfixes-5.0-1.fc15.x86_64
libXinerama-1.1.1-2.fc15.x86_64
libXi-1.4.3-1.fc15.x86_64
libXrandr-1.3.1-2.fc15.x86_64
libXrender-0.9.6-2.fc15.x86_64
libXt-1.1.0-1.fc15.x86_64
libX11-1.4.3-1.fc15.x86_64
ncurses-libs-5.8-2.20110319.fc15.x86_64
nss-softokn-freebl-3.12.10-2.fc15.x86_64
pango-1.28.4-1.fc15.x86_64
perl-libs-5.12.4-159.fc15.x86_64
pixman-0.20.2-2.fc15.x86_64
python-libs-2.7.1-7.fc15.x86_64
ruby-libs-1.8.7.334-1.fc15.x86_64
zlib-1.2.5-3.fc15.x86_64

BTW I still have a feeling that this issue is related to locale settings, IBus and forking of the GVIM from console. I still receive every time new file is opened the following warning:

(gvim:15318): IBUS-WARNING **: Create input context failed: Timeout was reached.

If I open GVIM and just (slowly) browse around, I never (well I waited 10 minutes at most) get this message. Once I press '/' to begin search, the prompt appears in 7s and from now, the GVIM behaves smooth. After 30s from pressing the '/', the warning appears on my terminal.

So what triggers the slash? Why there is the IBUS warning. Give us please some clue. Then we might be able to help you to debug this issue.

I have experimentally remove IBus and GVIM started work smoothly. I have reinstalled IBus, GVIM is lagging. Could you please pay some attention to GVIM <=> IBUS relation?

(In reply to comment #26)
This was obvious since the initial report:

 "(gvim:5333): IBUS-WARNING **:
  org.freedesktop.IBus.InputContext.ProcessKeyEvent: Timeout was reached"

just to add more info for my setup,

if I 'Quit' the ibus-daemon from the status bar applet (don't know what the name is), the menu item in the upper right of my gnome-shell, gvim works as normal.

when I select 'Restart' from said menu applet thingie, gvim pauses until I press '/'

I have created a current F15 live CD based upon the standard Fedora kickstart files including "fedora" and "updates" repositories. After pulling in vim-X11 from the running live session, logging out and in again, gvim works absolutely as expected in a GNOME session. This observation holds when I change the keyboard layout from US to German.
I never do system upgrades of an installed Fedora release. I always install Fedora from scratch. Maybe an update issue?

Installed packages related to vim-X11 are:
atk-2.0.0-1.fc15.i686
cairo-1.10.2-3.fc15.i686
expat-2.0.1-11.fc15.i686
fontconfig-2.8.0-3.fc15.i686
freetype-2.4.4-4.fc15.i686
gdk-pixbuf2-2.23.3-2.fc15.i686
glib2-2.28.8-1.fc15.i686
glibc-2.14-4.i686
gpm-libs-1.20.6-16.fc15.i686
gtk2-2.24.4-2.fc15.i686
libacl-2.2.49-9.fc15.i686
libattr-2.4.44-7.fc15.i686
libgcc-4.6.0-9.fc15.i686
libICE-1.0.6-3.fc15.i686
libpng-1.2.44-3.fc15.i686
libselinux-2.0.99-4.fc15.i686
libSM-1.2.0-2.fc15.i686
libuuid-2.19.1-1.3.fc15.i686
libX11-1.4.3-1.fc15.i686
libXau-1.0.6-2.fc15.i686
libxcb-1.7-2.fc15.i686
libXcomposite-0.4.3-2.fc15.i686
libXcursor-1.1.11-3.fc15.i686
libXdamage-1.1.3-2.fc15.i686
libXext-1.2.0-2.fc15.i686
libXfixes-5.0-1.fc15.i686
libXi-1.4.3-1.fc15.i686
libXinerama-1.1.1-2.fc15.i686
libXrandr-1.3.1-2.fc15.i686
libXrender-0.9.6-2.fc15.i686
libXt-1.1.0-1.fc15.i686
ncurses-libs-5.8-2.20110319.fc15.i686
nss-softokn-freebl-3.12.10-2.fc15.i686
pango-1.28.4-1.fc15.i686
perl-libs-5.12.4-159.fc15.i686
pixman-0.20.2-2.fc15.i686
python-libs-2.7.1-7.fc15.i686
ruby-libs-1.8.7.334-1.fc15.i686
zlib-1.2.5-3.fc15.i686

(In reply to comment #29)
ibus-1.3.99.20110419-9.fc15.i686
ibus-anthy-1.2.6-2.fc15.i686
ibus-chewing-1.3.9.2-3.fc15.i686
ibus-gtk2-1.3.99.20110419-9.fc15.i686
ibus-gtk3-1.3.99.20110419-9.fc15.i686
ibus-hangul-1.3.1-3.fc15.i686
ibus-libs-1.3.99.20110419-9.fc15.i686
ibus-m17n-1.3.2-5.fc15.i686
ibus-pinyin-1.3.99.20110520-1.fc15.i686
ibus-pinyin-db-android-1.3.99.20110520-1.fc15.noarch
ibus-rawcode-1.3.1.20100707-4.fc15.i686

(In reply to comment #29)
>

Yes, I can confirm launching `gvim` from terminal works well in gnome3. But did you check other environments, such as those listed in my previous comment #16?

I have enabled updates-testing, and have vim-x11-7.3.138-1 and ibus-1.3.99.20110419-10. The result is the same as in comment #16.

(In reply to comment #31)
I had filed this bug as a gvim/GNOME3 issue which appears to be resolved now. Any remaining issues with other desktop environments are different bugs and should be reported separately.

Really? resolved? Don't assume that that is the case. Thank you for opening it in the first place, but it still exists for others in the GNOME3 environment.

(In reply to comment #33)
> .. it still exists for others in the GNOME3 environment.

Have a look at comment 29 and comment 30, please. If this issue persists in the GNOME3 desktop environment, then this is probably an upgrade or an update issue.
I recommend creating a fresh user account to avoid interference with old custom settings. If you do not feel like installing F15 from scratch, then you can still try a current F15 live spin by means of livecd-creator and verify whether gvim exhibits any strange behaviour.

I can confirm that this issue persists in ibus and gvim.
A few days ago I switched from GNOME3 to XFCE, and since then I experience this problem which makes gvim unusable for me.

Note that I use ibus with its pinyin chinese IM.

I can confirm this is happening on my Fedora 15. I don't like the feeling of the new GNOME3, it looks raw and unpolished so I stick to KDE.

Every time I need to use gvim I have to quit the IBUS applet. It's annoying especially since I cannot find proper menu item to enable the IBUS applet again, until I quit the session and restart X.

I see the same problem in F15 as well.

Please see https://bugzilla.redhat.com/show_bug.cgi?id=727385 for a workaround and a proposed patch to vim to fix the issue. Most likely both bug reports are describing the same issue.

vim-7.3.315-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc14

vim-7.3.315-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc15

vim-7.3.315-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc16

Package vim-7.3.315-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing vim-7.3.315-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/vim-7.3.315-1.fc16
then log in and leave karma (feedback).

ChrisMague (eplus) wrote :
ChrisMague (eplus) wrote :

Probably IBUS under Xfce

(gvim:6437): IBUS-WARNING **: Create input context failed: Timeout was reached.

Paul Stewart (paulbrianstewart) wrote :

Hi Chris,

Do you have all the latest updates from the update-manager installed?

ChrisMague (eplus) wrote :

did an apt-get update/grade as of Mon Sep 26 08:19:34 PDT 2011

gvim -f file is instantly responsive

vim-7.3.315-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.

I can confirm that this is fixed on my box.

vim-7.3.315-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.

vim-7.3.315-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.

georgehu (geohuz) wrote :

This is annoying issue. I have the same problem on fedora 15 at first, but they finally has a patch to fix it. Now I'm on ubuntu 11.10, got the same problem. I know it is with ibus, hope somebody can fix it.

It seems that this problem is already fixed by vim-7.3.315.
But current vim-gtk package is 7.3.154.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vim (Ubuntu):
status: New → Confirmed
Szabolcs (szhorvat) wrote :

Are there updated packages (with the fix) for Oneiric somewhere, that I could install now?

Szabolcs (szhorvat) wrote :

There's a related issue:

The global menu either doesn't show *at all* with gvim, or it shows in the vim window (it's not global).
This problem disappears too when starting gvim with "gvim -f", hence it might be related.

Szabolcs (szhorvat) wrote :

The bug for that is: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/776499 (sorry for so many replies)

Rex Tsai (chihchun) wrote :

I applied the patch from redhat[1], seems it fixed the issue. You can test it from my ppa[2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=727385
[2] https://launchpad.net/~chihchun/+archive/experimental

Rex Tsai (chihchun) wrote :

This bug is fixed in upstream, since vim-7.3.315. Precise has upgtraded to 2:7.3.333-1ubuntu3.

Changed in vim (Ubuntu):
assignee: nobody → Rex Tsai (chihchun)
Rex Tsai (chihchun) wrote :

Please help to test the ppa, then we can request for SRU.

Changed in vim (Ubuntu):
status: Confirmed → In Progress

The attachment "debdiff.patch" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Niall Murphy (nmurphy) wrote :

Thanks for this Rex.
I have installed the packages from the PPA.

I can now start gvim from a terminal and gvim is immediately responsive.
gVim seems to be back to its former speed, I can edit large files with folds again!

However, when gvim is run from a terminal it does not fork by default.
Running "gvim --nofork" and "gvim" gives the same effect.
(I am almost certain I have removed all aliases/scripts that inserted --nofork)

Rex Tsai (chihchun) wrote :

Hi, Niall

I am confused, do you mean

1. you have same responsive issue with "gvim --nofork" with the patch applied.
or
2. you can run "gvim --nofork" without the patch, and gvim is immediately responsive.

I can not reproduce the problem with the patch applied.

Niall Murphy (nmurphy) wrote :

Hi Rex,
Sorry, let me explain again.

With the patch gvim is fully responsive.
It is also fully responsive with "gvim --nofork".

There is a new issue raised by the patch:
Running "gvim" from a terminal now acts identically to "gvim --nofork" in the sense that
 it does not fork from the bash process.
To have the terminal free I must run "gvim &".

Rex Tsai (chihchun) wrote :

Niall, Thanks for clarify the new problem introduced by the patch.

Didier Roche (didrocks) wrote :

So, I guess we don't really want to sponsor this patch with this regression. Can you please have a look at it and resuscribe ubuntu-sponsors if you get a fix? Thanks again for your work there :)

Rex Tsai (chihchun) wrote :

Didier Yes, I will investge the regression issue and upload a new patch when I am available. (anyone who has time is welcome to do it)

I can not remove ubuntu-sponsors from subscriber list, so just removed the patch.

Rex Tsai (chihchun) wrote :

I have the new patch from upstream vcs. It's not a small change, please review and test it.

  * debian/patches/debian/gtk-fork.patch:
    - patch from upstream v7-3-315. (LP: #856779)
      Problem: Opening a window before forking causes problems for GTK.
      Solution: Fork first, create the window in the child and report back to the
                  parent process whether it worked. If successful the parent exits,
                  if unsuccessful the child exits and the parent continues in the
                  terminal. (Tim Starling)

I could not branch oneiric version[1] for propose a merging review. But you can my debdiff which fix the problem. Test build will be available in my ppa[2].

[1] https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/vim/oneiric
[2] https://launchpad.net/~chihchun/+archive/experimental 2:7.3.154+hg~74503f6ee649-2ubuntu3.1rex1

Niall Murphy (nmurphy) wrote :

Hi Rex,

This patch is working perfectly!
Good work!
Thank you.

The patch works for me as well.
Thanks.

Colin Watson (cjwatson) on 2012-01-27
Changed in vim (Ubuntu Oneiric):
assignee: nobody → Rex Tsai (chihchun)
status: New → In Progress
Changed in vim (Ubuntu):
status: In Progress → Fix Released
Colin Watson (cjwatson) wrote :

Thanks for this patch and the preliminary testing. I'll send it off to oneiric-proposed now.

Bryce Harrington (bryce) on 2012-01-27
description: updated
Serge Hallyn (serge-hallyn) wrote :

(apologies if this has been discussed out of band)

Could someone who can reproduce this bug fill in the top part of the description, especially part 4, a detailed test case? The proposed package is waiting to be accepted into oneiric-proposed, but before it can be accepted there the description will need to be filled in (and "ubuntu-sru" subscribed to the bug).

David Barnett (mu-mind) wrote :

Can anyone confirm that you must have ibus installed to experience the bug? I have ibus installed and experience the hang literally every time I open a gvim window. It seems to vary how long it takes to recover each time.

David Barnett (mu-mind) wrote :

Updated, but I have no idea on Development Fix or Stable Fix, and I'm not quite sure what would be a reasonable value for Regression Potential.

description: updated
description: updated
Sebastien Bacher (seb128) wrote :

Colin says that the upload was rejected without visibile, it's still in there if we want to bring it back:
https://launchpad.net/ubuntu/oneiric/+queue?queue_state=4&queue_text=vim

Chris, Martin, any idea what happened there? Colin suggested that you could bring it back to the unapproved queue if that was an error

Martin Pitt (pitti) wrote :

The upload did not refer to any Launchpad bug, which is a strict requirement for SRUs. I mailed Rex about this back then.

Rex Tsai (chihchun) wrote :

Hi, I added the LP bug refernece in the debian/changelog. Please sponsor the pacakge.

description: updated
Rex Tsai (chihchun) wrote :

David Barnett, No, the issue is not related to ibus.

David Barnett (mu-mind) wrote :

Okay, I removed the mention of ibus from the "Test Case".

So does this issue effect everyone with this version of gvim, or is there any other software that affects it?

description: updated
Roberto (robertokl) wrote :

Hi Guys.. I'm newbie @ linux and I think I'm having the same issue reported here, but I wasn't able to apply the patch that Rex provided. I added the PPA (sudo add-apt-repository ppa:chihchun/experimental) and upgraded the packages, but the problem keeps happening.

Could you help me? Maybe a step-by-step of what I should do :)

Thank you.

Jamie Strandboge (jdstrand) wrote :

Thanks Rex! I verified the revised patch against upstream. debian/changelog should reference oneiric-proposed, not oneiric. Additionally since the package uses a patch system that supports comments, debian/patches/debian/gtk-fork.patch should be using DEP-3 comments which would clean up the changelog significantly. Since this fix has been slow to get into the archive, I have made these changes and uploaded to oneiric-proposed.

I was unable to reproduce the issue based on the test case. Could someone affected by this update the test case accordingly? Unsubscribing ubuntu-sponsors and subscribing ubuntu-sru and sru-verification.

Changed in vim (Ubuntu Oneiric):
status: In Progress → Confirmed

Hello ChrisMague, or anyone else affected,

Accepted vim into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in vim (Ubuntu Oneiric):
status: Confirmed → Fix Committed
tags: added: verification-needed

Strange.
I'm using ubuntu precise (vim 7.3.429) and after entering "gvim" the program still takes very long to load. The workaround described in http://tots.1o24.org/gvim-problems-after-upgrading-to-ubuntu-11-10-oneiric-ocelot/ works fine.

Rex Tsai (chihchun) wrote :

quantenemitter, the fix is in oneiric-proposed. If you found the problem in precise, plesae file another bug. Thanks.

djwong (djwong) wrote :

I couldn't find a bug report against the Precise gvim, so I filed bug #987707.

Sebastien Bacher (seb128) wrote :

Could someone who had the issue confirm that the fix works so it can be validated as a correct update and move out of staging?

sense (opaperjam) wrote :

My system: ubuntu 11.10
vim-gtk version: 2:7.3.154+hg~74503f6ee649-2ubuntu3.1
It work for me.

Martin Pitt (pitti) on 2012-05-18
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vim - 2:7.3.154+hg~74503f6ee649-2ubuntu3.1

---------------
vim (2:7.3.154+hg~74503f6ee649-2ubuntu3.1) oneiric-proposed; urgency=low

  * debian/patches/debian/gtk-fork.patch: Opening a window before forking
    causes problems for GTK (LP: #856779)
 -- Rex Tsai () <email address hidden> Fri, 13 Jan 2012 20:14:24 +0800

Changed in vim (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Changed in vim (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.