I've just upgraded to gvim-7.0 [ acl (-aqua) -bash-completion -cscope +gnome +gpm +gtk +motif -mzscheme -netbeans -nextaw +nls +perl +python +ruby ], tried the new tab functionality and found a bug that is easily reproducable like this for me: 1.) open gvim 2.) maximize gvim (this is important) 3.) <Esc>:tabnew foo.txt 4.) try to enter a command to realize that the commandline is no longer visible 5.) unmaximize gvim and the commandline is back (at least 3/4 of it) Portage 2203-svn (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.16-gentoo-r6 i686) ================================================================= System uname: 2.6.16-gentoo-r6 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks sandbox sfperms strict test" GENTOO_MIRRORS="http://gentoo.inode.at/ " LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.1/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac aalib acpi alsa apm audiofile avi berkdb bitmap-fonts bonobo bzip2 cairo cdr cli crypt css cups curl dbus directfb dri dts dvd dvdr dvdread eds emboss encode exif expat fam fbcon ffmpeg firefox flac foomaticdb fortran gd gdbm gif ginac glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal icq idn imagemagick imlib ipv6 isdnlog java javascript jpeg jpeg2k junit lcms libg++ libwww mad matroska mikmod mime mmx mmxext mng motif mozsvg mp3 mpeg msn nautilus ncurses nls nptl nsplugin nvidia offensive ogg oggvorbis openal opengl pam pcre pdflib perl plotutils png posix pppd python quicktime readline real reflection ruby sdl session slang sockets speex spell spl sqlite sqlite3 sse ssl subtitles svg svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wma xine xml xml2 xmms xorg xv xvid zlib linguas_en linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Hmm, I can't seem to reproduce this bug. Are you sure your window manager isn't just doing a poor job of maximizing the window, and it ends up hiding the lower chunk of your window beneath something, or off screen?
> Are you sure your window manager isn't > just doing a poor job of maximizing the window, and it ends up hiding the lower > chunk of your window beneath something, or off screen? Hmm, i'm using metacity-2.14.5 USE="-debug -xinerama" and gvim-7.0.17 USE="gnome gpm gtk nls perl python ruby -acl (-aqua) -bash-completion -cscope -motif -mzscheme -netbeans -nextaw" at the moment and still experience this behaviour. I don't think that this is the wm's fault, as i experienece this only if i maximize the window _before_ opening a new tab. If i do "unmaximize->maximize" after step 4., only 3/4 of the commandline are back; that again speaks against the wm theory in my opinion. However, it is very likely that this bug is something that only appears in a very special context. Otherwise, there would have been other users adding their comments here. Let's see if upgrading to gvim-7.0.91 solves this issue for me ...
> Let's see if upgrading to gvim-7.0.91 solves this issue for me ... unfortunately not :-(
I've had a similar problem on a much wider scale until I turned off the gtk flag. When I include gtk-support gvim starts up with showing no chars within the editor-window at all (the menu is alright). Resizing lets them all appear, until they get in touch with the cursor or get marked. Any cursorform makes the chars vanish as a whole. The _pixel_ that are superimposed by menus that flip open or are moved outside of the screen (moving the window) become visible thereafter. It somehow seems that chars are not redrawn within a cursoristically context. <...> No gtk is no problem to me as I turn off the menu in any case, and other gtk-support-apps(e.g. mplayer (and everything else btw)) seem to work. This must be specific to my installation/system (this extent and no bugreport anywhere) but if someone is interested, I will dig a bit deeper. gtk+-reinstalling without xinerama showed no difference.
Hmm, so I'll say that this seems to be a bug in vim. I've been able to reproduce it myself a month or so ago. But, now, in version 7.0.174, it seems to behave as it should. Would you mind testing and seeing if it works in that version? I think specifically patch 7.0.149 might have fixed it. So, please try the latest version in the tree (7.0.174), and tell me how that goes.
hmm, i'm still experiencing more or less the same with app-editors/gvim-7.0.174 USE="gnome gpm gtk nls perl python ruby -acl (-aqua) -bash-completion -cscope -motif -mzscheme -netbeans -nextaw" and x11-wm/metacity-2.16.3 USE="-debug -xinerama" the only thing that has improved for me (see comment #0 - 5.)), is that after unmaximizing/maximizing not only 3/4 but 4/4 of the commandline are back.
Regarding my bug (comment 4) Sorry for my intermezzoing but it seemed a bit similar. It started working when I tried gvim-7.0.174 with gtk Next time I'll try overlay-versions in advance.(I'm new at gentoo) ...so I rushed forward to gvim-7.0.174 with gtk and now I'm unable to reproduce the bug with any ebuild(17,91,146). I even pulled the plug to clear the memory. Actually I don't even know if a rebuild of the non-overlay version(.17) would have worked this time in the first place. I'm still getting to know about gentoo this and that and do change a lot configs, and there was an "emerge --update --deep --newuse world" inbetween. So maybe it were prevailing circumstances.
Sorry, Matthias, but I think I'm out of suggestions. This is a bug with the source code of the package, so I'd suggest you send a message to the vim-dev mailing list and folks will be able to help you better there. When Bram releases an official patch, I'll include it in Gentoo. See http://www.vim.org/maillist.php for more info on posting to vim-dev.
