Bad resizing in console Vim 7.1.138
Raúl Núñez
Yes, I know, my Vim version is a bit outdated, but from what I've seen
in the README's of the patches for 7.1 and 7.2, this bug has not been
addressed (and maybe it is not a bug at all). I'm asking here and not in
vim_dev just in case it's my fault and not a bug in Vim. If nobody can
reproduce I'll build a Vim myself with latest patches and retest.
The bug happens with and without my rc files, I've tested both, and
seems to depend on using the "-o" option with just one file.
If "-o" is used and console vim is opened in a terminal emulator (I've
tested with gnome-terminal and xcfe4-terminal) with a geometry where the
lines are *LESS* than the number of lines in the opened file, then the
screen is not correctly redrawn, even when scrolling. The screen appears
as if the number of lines was 24. In this case, a screen capture is
worth thousand messages:
http://www.dervishd.net/vim-bad.png
If the file is short enough, this doesn't happen:
http://www.dervishd.net/vim-good.png
To reproduce, run "gnome-terminal --geometry=80x30 -x vim -o file.txt",
where "file.txt" is a file with more than 30 lines. I haven't found the
exact number of excess lines that causes the bug, so better try with a
file of more than 100 lines so you can scroll, because the screen is
correctly redrawn again if you scroll to the end of file, not using "G",
but using PgDn repeteadly.
The bug doesn't happen if the "-o" option is not used.
Raúl "DervishD" Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...
Richard Hartmann
<ra...@dervishd.net> wrote:
> http://www.dervishd.net/vim-bad.png
I can't reproduce this with:
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 12 2008 03:23:45)
Included patches: 1-32
Compiled by richih@adamantium
Huge version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +postscript
+printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
-toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 +xfontset -xim
+xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/local/vim_extended/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2
-I/usr/include/python2.5 -pthread
Linking: gcc -L/usr/local/lib -o vim -lXt -lncurses
-L/usr/lib/python2.5/config -lpython2.5 -lutil -lm -Xlinker
-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
Note that I have a few unrelated patches in my Vim.
Richard
Raúl Núñez
On Wed, 26 Nov 2008 18:11:56 +0100, Richard Hartmann dixit:
> On Wed, Nov 26, 2008 at 10:15, Raúl Núñez de Arenas Coronado
> <ra...@dervishd.net> wrote:
>
> > http://www.dervishd.net/vim-bad.png
>
> I can't reproduce this with:
>
> VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 12 2008 03:23:45)
> Included patches: 1-32
[...]
> Note that I have a few unrelated patches in my Vim.
So, it may be a problem of features and/or missing patches on my part.
The version I'm using is the one shipped with Ubuntu and with no GUI.
I'm afraid I will have to build a version myself and carry some tests.
Maybe a session with the debugger, if I can afford the time.
Thanks for testing, Richard, and for the included data.
Richard Hartmann
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct 20 2008 16:23:13)
Included patches: 1-25
Compiled by jame...@debian.org
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim
+xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/directfb
-I/usr/include/libpng12 -I/usr/include/pixman-1 -DORBIT2=1 -pthread
-D_REENTRANT -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
-I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -Wall -g -O2 -D_REENTRANT -D_GNU_SOURCE
-DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE
-I/usr/include/python2.5 -pthread -I/usr/include/tcl8.4
-D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
-I/usr/lib/ruby/1.8/i486-linux
Linking: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E
-Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0
-lgmodule-2.0 -lglib-2.0 -lgnomeui-2 -lbonoboui-2 -lgnomevfs-2
-lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation
-lORBit-2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgconf-2
-lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lXt
-lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib
-L/usr/lib/perl/5.10/CORE -lperl -L/usr/lib/python2.5/config
-lpython2.5 -lutil -Xlinker -export-dynamic -Wl,-O1
-Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.4 -lieee -lruby1.8 -lm
Charles Campbell
I tried it on Centos 5.2 with 7.2.49 and had nothing untoward happen.
May I suggest that you try it again, but with
gnome-terminal --geometry=80x30 -x vim -u NONE -N -o file.txt
Regards,
Chip Campbell
Dominique Pelle
> In this case, a screen capture is worth thousand messages:
>
> http://www.dervishd.net/vim-bad.png
>
> If the file is short enough, this doesn't happen:
>
> http://www.dervishd.net/vim-good.png
>
> To reproduce, run "gnome-terminal --geometry=80x30 -x vim -o file.txt",
> where "file.txt" is a file with more than 30 lines. I haven't found the
> exact number of excess lines that causes the bug, so better try with a
> file of more than 100 lines so you can scroll, because the screen is
> correctly redrawn again if you scroll to the end of file, not using "G",
> but using PgDn repeteadly.
>
> The bug doesn't happen if the "-o" option is not used.
I can't reproduce it either using vim-7.2.49 or Vim-7.1.314 on
Linux in a terminal. You need to try with "vim -u NONE -o ..."
to rule out things from ~/.vim/ or ~/.vimrc.
-- Dominique
Raúl Núñez
On Wed, 26 Nov 2008 13:14:43 -0500, Charles Campbell dixit:
> Raúl Núñez de Arenas Coronado wrote:
> > To reproduce, run "gnome-terminal --geometry=80x30 -x vim -o
> > file.txt", where "file.txt" is a file with more than 30 lines. I
> > haven't found the exact number of excess lines that causes the bug,
> > so better try with a file of more than 100 lines so you can scroll,
> > because the screen is correctly redrawn again if you scroll to the
> > end of file, not using "G", but using PgDn repeteadly.
> >
> > The bug doesn't happen if the "-o" option is not used.
> >
> >
> I tried it on Centos 5.2 with 7.2.49 and had nothing untoward
> happen. May I suggest that you try it again, but with
>
> gnome-terminal --geometry=80x30 -x vim -u NONE -N -o file.txt
I tried that (I told in my first message, only I didn't refer to it as
"-u NONE", I told "no rc files". My bad O:))).
The problem happens but it is not as visual because there is no
statusline. But it happens, definitely. I have to investigate it.
Raúl Núñez
On Wed, 26 Nov 2008 19:23:09 +0100, Dominique Pelle dixit:
> 2008/11/26 Raúl Núñez de Arenas Coronado skribis:
> > To reproduce, run "gnome-terminal --geometry=80x30 -x vim -o
> > file.txt", where "file.txt" is a file with more than 30 lines. I
> > haven't found the exact number of excess lines that causes the bug,
> > so better try with a file of more than 100 lines so you can scroll,
> > because the screen is correctly redrawn again if you scroll to the
> > end of file, not using "G", but using PgDn repeteadly.
> >
> > The bug doesn't happen if the "-o" option is not used.
>
> I can't reproduce it either using vim-7.2.49 or Vim-7.1.314 on
> Linux in a terminal. You need to try with "vim -u NONE -o ..."
> to rule out things from ~/.vim/ or ~/.vimrc.
I already tried that and the problem persists although it is much less
visible because there is no statusline. It may a bug on the Ubuntu
version :?? It may be a bug in the terminal emulators, because I have
tested more than one, all of them used libvte, so...
Thanks :)
Raúl Núñez
On Wed, 26 Nov 2008 18:58:26 +0100, Richard Hartmann dixit:
> This one is OK, as well (both were tested with my vimrc and no RC at
> all):
Thanks for testing, Richard. Definitely, not a Vim bug, but a bug in
something I have here. I'll test in different Ubuntu's, just to check
that it is not a problem in *my* box, and if I can reproduce, I'll try
to check against a self compiled version with the Ubuntu sources and
with the official sources.
It may be even a problem with some disabled feature :??? I'll post the
results here if I found anything.
Tony Mechelynck
> Saluton Dominique :)
>
> On Wed, 26 Nov 2008 19:23:09 +0100, Dominique Pelle dixit:
>> 2008/11/26 Raúl Núñez de Arenas Coronado skribis:
>>> To reproduce, run "gnome-terminal --geometry=80x30 -x vim -o
>>> file.txt", where "file.txt" is a file with more than 30 lines. I
>>> haven't found the exact number of excess lines that causes the bug,
>>> so better try with a file of more than 100 lines so you can scroll,
>>> because the screen is correctly redrawn again if you scroll to the
>>> end of file, not using "G", but using PgDn repeteadly.
>>>
>>> The bug doesn't happen if the "-o" option is not used.
>> I can't reproduce it either using vim-7.2.49 or Vim-7.1.314 on
>> Linux in a terminal. You need to try with "vim -u NONE -o ..."
>> to rule out things from ~/.vim/ or ~/.vimrc.
>
> I already tried that and the problem persists although it is much less
> visible because there is no statusline. It may a bug on the Ubuntu
> version :?? It may be a bug in the terminal emulators, because I have
> tested more than one, all of them used libvte, so...
>
> Thanks :)
>
> Raúl "DervishD" Núñez de Arenas Coronado
What about testing it in a raw-text terminal? Hit Ctrl-Alt-F2, log in by
username & password, then invoke vim from there. Since that terminal is
not resizable, you shouldn't try to set 'lines' or 'columns' to anything
other than the default (usually 80 columns by 25 lines, but sometimes
you can select a different size at boot time).
Ctrl-Alt-F7 will bring you back to the X11 terminal.
Best regards,
Tony.
--
The soul would have no rainbow had the eyes no tears.
Raúl Núñez
On Wed, 26 Nov 2008 20:52:30 +0100, Tony Mechelynck dixit:
> >> I can't reproduce it either using vim-7.2.49 or Vim-7.1.314 on
> >> Linux in a terminal. You need to try with "vim -u NONE -o ..."
> >> to rule out things from ~/.vim/ or ~/.vimrc.
> >
> > I already tried that and the problem persists although it is much
> > less visible because there is no statusline. It may a bug on the
> > Ubuntu version :?? It may be a bug in the terminal emulators,
> > because I have tested more than one, all of them used libvte, so...
>
> What about testing it in a raw-text terminal? Hit Ctrl-Alt-F2, log in
> by username & password, then invoke vim from there. Since that
> terminal is not resizable, you shouldn't try to set 'lines' or
> 'columns' to anything other than the default (usually 80 columns by
> 25 lines, but sometimes you can select a different size at boot time).
I'm not setting "lines" and "columns", because I prefer Vim to take them
from the environment or by asking the terminal. Basically, I resize my
terminals wherever I need and I can launch Vim using whatever size I
have in that moment.
The problem doesn't happen in a virtual terminal and doesn't happen if I
resize the terminal and *after that* I launch Vim (but then the
environment variables LINES and COLUMNS are set by the shell, so...).
Maybe Vim is asking the terminal emulator for the size when the terminal
emulator is still at 80x25 (the default size for most of them) and after
that the terminal emulator switches to whatever geometry I specified,
sends SIGWINCH to Vim in a bad moment and everything messes up. What
amazes me the most is that the problem only happens when using "-o". I
don't understand why :??
I think my best bet is to try using my self compiled Vim. If the problem
only happens with the version shipped with Ubuntu, then I'll investigate
any changes to the sources and/or building.
Thanks :)
Raúl "DervishD" Núñez de Arenas Coronado
Ben Schmidt
I seem to recall seeing something similar at some stage, either on the
mailing list, or on my machine, so it yet may be a Vim bug.
> So, it may be a problem of features and/or missing patches on my part.
> The version I'm using is the one shipped with Ubuntu and with no GUI.
True. It was long ago I saw it, so it may well be fixed.
Alternatively, it could be a terminfo/termcap problem, though that seems
unlikely as you can reproduce it in a number of different terminal
emulators, and it only happens with -o, so yeah; hmm.
Ben.
Kanru
wrote:
> from the environment or by asking the terminal. Basically, I resize my
> terminals wherever I need and I can launch Vim using whatever size I
> have in that moment.
>
> The problem doesn't happen in a virtual terminal and doesn't happen if I
> resize the terminal and *after that* I launch Vim (but then the
> environment variables LINES and COLUMNS are set by the shell, so...).
> Maybe Vim is asking the terminal emulator for the size when the terminal
> emulator is still at 80x25 (the default size for most of them) and after
> that the terminal emulator switches to whatever geometry I specified,
> sends SIGWINCH to Vim in a bad moment and everything messes up. What
> amazes me the most is that the problem only happens when using "-o". I
> don't understand why :??
>
enabled 2.6.27 and maybe priors. If so, you can either use a non-
preempt version or upgrade to a new one.
[1]: http://search.gmane.org/?query=TIOCSWINSZ&group=gmane.linux.kernel&sort=date
Kanru
> On Nov 27, 4:16 am, Raúl Núñez de Arenas Coronado <r...@dervishd.net>
> wrote:
>
> > I'm not setting "lines" and "columns", because I prefer Vim to take them
> > from the environment or by asking the terminal. Basically, I resize my
> > terminals wherever I need and I can launch Vim using whatever size I
> > have in that moment.
>
> > The problem doesn't happen in a virtual terminal and doesn't happen if I
> > resize the terminal and *after that* I launch Vim (but then the
> > environment variables LINES and COLUMNS are set by the shell, so...).
> > Maybe Vim is asking the terminal emulator for the size when the terminal
> > emulator is still at 80x25 (the default size for most of them) and after
> > that the terminal emulator switches to whatever geometry I specified,
> > sends SIGWINCH to Vim in a bad moment and everything messes up. What
> > amazes me the most is that the problem only happens when using "-o". I
> > don't understand why :??
>
> I guess you get hit by a kernel bug[1]. This bug exists in preempt
> enabled 2.6.27 and maybe priors. If so, you can either use a non-
> preempt version or upgrade to a new one.
>
> [1]:http://search.gmane.org/?query=TIOCSWINSZ&group=gmane.linux.kernel&so...
Raúl Núñez
On Wed, 26 Nov 2008 18:36:14 -0800 (PST), Kanru dixit:
> I guess you get hit by a kernel bug[1]. This bug exists in preempt
> enabled 2.6.27 and maybe priors. If so, you can either use a non-
> preempt version or upgrade to a new one.
>
> [1]:
> http://search.gmane.org/?query=TIOCSWINSZ&group=gmane.linux.kernel&sort=date
Looks like that, certainly. I'm currently using 2.6.24 now, which may be
affected by the bug, too.
I'll test with a self-compiled vim, just in case.
Thanks for pointing! :)
Raúl Núñez
On Thu, 27 Nov 2008 08:50:07 +1100, Ben Schmidt dixit:
> >>> http://www.dervishd.net/vim-bad.png
>
> I seem to recall seeing something similar at some stage, either on the
> mailing list, or on my machine, so it yet may be a Vim bug.
Or a kernel bug, from what another member (Kanru) pointed. Related with
resizing code on the kernel part of PTY handling.
If I can reproduce with a self built Vim using the latest sources, which
work for other list members, then the problem is in my box: kernel,
libraries or whatever. I still have my old system saved in a DVD, and I
built myself all the software for that, a "homemade Linux box". I can
check there, because the kernel is pretty old, maybe 2.6.13 or so.