vim (in terminal) fails to redraw after window resizing

762 views
Skip to first unread message

Bill Sun

unread,
Oct 6, 2011, 1:29:24 PM10/6/11
to vim...@googlegroups.com
Hi,

I updated my Vim (from 1-250 to 1-333), after that update, Vim fails to
redraw the window (if the window is enlarged, Vim won't fill the gap,
which was filled by Vim automatically in the older version) instantly
when I resize the window. So I have to put my cursor on Vim (under
xterm) and press some (maybe any) key to make it redraw itself.

Err... It's a little bit hard to explain that problem. I made an ogv to
illustrate that (Sorry, I cannot access to most video store websites, so
I have to attach that file).

I'm using Arch Linux (x86_64), awesome window manager.
Vim version: (See attachment below)
System information:
Linux 3.0.6
X server 1.10.4
xterm 275
awesome 3.4.10


Cheers,
Bill Sun

vim_redraw_problem.ogv.xz
vim_version.txt

Taylor Hedberg

unread,
Oct 6, 2011, 2:59:24 PM10/6/11
to vim...@googlegroups.com
I've noticed the same problem recently. I had intended to go through the
Mercurial repo and bisect it down to the specific patch caused the
regression, but I haven't had time to do so.

I think the basic underlying problem is that Vim is not properly
responding to SIGWINCH, which is the POSIX signal sent to X clients when
their window changes size. It should probably just do a screen redraw
when the signal is received, but something is preventing that.

I'm also on Arch Linux, using Vim in rxvt-unicode with xmonad as the
window manager.

Taylor Hedberg

unread,
Oct 6, 2011, 3:03:56 PM10/6/11
to vim...@googlegroups.com
Taylor Hedberg, Thu 2011-10-06 @ 14:59:24-0400:

> I think the basic underlying problem is that Vim is not properly
> responding to SIGWINCH, which is the POSIX signal sent to X clients
> when their window changes size.

Actually, I should have said that SIGWINCH is sent to terminal
applications when their terminal window changes size. It's not an X
thing. But the problem is the same, regardless.

Bram Moolenaar

unread,
Oct 6, 2011, 5:21:29 PM10/6/11
to Bill Sun, vim...@googlegroups.com

Bill Sun wrote:

I have noticed this too. Haven't been able to guess what causes it. If
someone can find out if a specific patch has introduced this it would
help a lot. It might also depend on the xterm version (although I don't
think I updated it recently).

--
"Oh, no! NOT the Spanish Inquisition!"
"NOBODY expects the Spanish Inquisition!!!"
-- Monty Python sketch --
"Oh, no! NOT another option!"
"EVERYBODY expects another option!!!"
-- Discussion in vim-dev mailing list --

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Taylor Hedberg

unread,
Oct 6, 2011, 6:28:10 PM10/6/11
to vim...@googlegroups.com, Bill Sun
Bram Moolenaar, Thu 2011-10-06 @ 23:21:29+0200:

> I have noticed this too. Haven't been able to guess what causes it.
> If someone can find out if a specific patch has introduced this it
> would help a lot. It might also depend on the xterm version (although
> I don't think I updated it recently).

OK, I just ran a hg bisect to track this down. Patch 7.3.295 appears to
be the culprit. Won't get a chance to look at the code until later, but
maybe you or someone else can take a look before then.

Peter Hofmann

unread,
Oct 6, 2011, 4:01:36 PM10/6/11
to vim...@googlegroups.com
Hi,

same over here. To me, it looks like this was introduced with patch 295.
I'm on Arch, too, also using XTerm and Awesome -- but it's the same with
Openbox.

Let me add that sometimes the window refreshes properly if you wait a
few seconds.

Cheers!
Peter

Peter Hofmann

unread,
Oct 6, 2011, 5:38:15 PM10/6/11
to v...@vim.org
Hi,

On Thu, Oct 06, 2011 at 11:21:29PM +0200, Bram Moolenaar wrote:
> If someone can find out if a specific patch has introduced this it
> would help a lot.

to me, it looks like this was introduced with patch 295.

I use the same software as Bill does, that is Arch Linux, XTerm, Awesome
(same versions as well).

Cheers!
Peter


PS.: I'm sorry if this mail arrives twice. I might have made a mistake
at first. :)

Taylor Hedberg

unread,
Oct 6, 2011, 10:02:35 PM10/6/11
to vim...@googlegroups.com, Bill Sun, vim...@vim.org
(Adding vim_dev to recipients...)

Bram Moolenaar, Thu 2011-10-06 @ 23:21:29+0200:
>

> Bill Sun wrote:
>
> > I updated my Vim (from 1-250 to 1-333), after that update, Vim fails to
> > redraw the window (if the window is enlarged, Vim won't fill the gap,
> > which was filled by Vim automatically in the older version) instantly
> > when I resize the window. So I have to put my cursor on Vim (under
> > xterm) and press some (maybe any) key to make it redraw itself.
> >
> > Err... It's a little bit hard to explain that problem. I made an ogv to
> > illustrate that (Sorry, I cannot access to most video store websites, so
> > I have to attach that file).
> >
> > I'm using Arch Linux (x86_64), awesome window manager.
> > Vim version: (See attachment below)
> > System information:
> > Linux 3.0.6
> > X server 1.10.4
> > xterm 275
> > awesome 3.4.10
>
> I have noticed this too. Haven't been able to guess what causes it. If
> someone can find out if a specific patch has introduced this it would
> help a lot. It might also depend on the xterm version (although I don't
> think I updated it recently).

Attached is a patch which fixes the issue.

Previously, if the terminal window was resized while Vim was waiting for
a character to be input (in the midst of a select(2) system call), the
resulting SIGWINCH would interrupt the syscall and set do_resize to
TRUE, as it should. However, since patch 295, the select call would then
immediately be retried, without checking do_resize to see if the window
needed to be redrawn.

With this patch, Vim will call handle_resize to redraw the window before
retrying the select call if a SIGWINCH was the reason why the select was
interrupted in the first place.

-Taylor Hedberg

vim_resize.patch

Bill Sun

unread,
Oct 6, 2011, 10:53:05 PM10/6/11
to vim...@googlegroups.com, Taylor Hedberg
On Thu, Oct 06, 2011 at 10:02:35PM -0400, Taylor Hedberg wrote:
> (Adding vim_dev to recipients...)
>
> Bram Moolenaar, Thu 2011-10-06 @ 23:21:29+0200:
>
> Attached is a patch which fixes the issue.
>
> Previously, if the terminal window was resized while Vim was waiting for
> a character to be input (in the midst of a select(2) system call), the
> resulting SIGWINCH would interrupt the syscall and set do_resize to
> TRUE, as it should. However, since patch 295, the select call would then
> immediately be retried, without checking do_resize to see if the window
> needed to be redrawn.
>
> With this patch, Vim will call handle_resize to redraw the window before
> retrying the select call if a SIGWINCH was the reason why the select was
> interrupted in the first place.
OK, that patch solved the problem (for 1-333).

Thanks.

Bram Moolenaar

unread,
Oct 8, 2011, 10:53:08 AM10/8/11
to Taylor Hedberg, vim...@googlegroups.com, Bill Sun, vim...@vim.org

Taylor Hedberg wrote:

Thanks for the patch! I'll check it out soon.


--
The real
trick is
this: to
keep the
lines as
short as
possible
and keep
the size
the same
yet free
from the
need for
hyphena-
Dammit!! (Matthew Winn)

Reply all
Reply to author
Forward
0 new messages