Re: vim (in terminal) fails to redraw after window resizing

34 views
Skip to first unread message

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
Reply all
Reply to author
Forward
0 new messages