gvim mode: Maximize/Tabs Bug in GNOME
Andy Walker
I've heard it's in KDE as well). If I click on the window manager's
maximize button, it fills the screen rather nicely, but if I then add
a tab, this resizes the window, pushing the bottom couple of lines off
of the screen. Restoring and re-maximizing fixes this (of course),
but if I ever go down below two tabs again and then add another, the
same thing happens again. set showtabline=2 fixes the issue, but it's
probably something you should know about anyway. My .gvimrc for
reference:
set guioptions+=M
let did_install_default_menus = 1
let did_install_syntax_menu = 1
source $HOME/.vim/menu.vim
set guifont=ProggySquareTTSZ\ 12
set columns=80 lines=50
set guioptions-=T "hide toolbar
set showtabline=2 "always show tab line to prevent resize bug.
colo marklar
"set gcr=a:blinkon0
set mouseshape=i-r:beam,s:updown,sd:udsizing,vs:leftright,vd:lrsizing,m:no,ml:up-arrow,v:beam
if has("autocmd")
au FocusLost *
\ set cursorcolumn |
\ set cursorline
au FocusGained *
\ set nocursorcolumn |
Bram Moolenaar
Andy Walker wrote:
> I've encountered a small annoyance in 7.2 (and earlier) in GNOME (and
> I've heard it's in KDE as well). If I click on the window manager's
> maximize button, it fills the screen rather nicely, but if I then add
> a tab, this resizes the window, pushing the bottom couple of lines off
> of the screen. Restoring and re-maximizing fixes this (of course),
> but if I ever go down below two tabs again and then add another, the
> same thing happens again. set showtabline=2 fixes the issue, but it's
> probably something you should know about anyway. My .gvimrc for
> reference:
[...]
This is a known problem, at least for the GTK version. The window
manager doesn't seem to matter for this.
GTK resizing has always been tricky. GTK wants to tell Vim the size of
the windows, while Vim wants ":set columns=N lines=M" to work.
--
hundred-and-one symptoms of being an internet addict:
189. You put your e-mail address in the upper left-hand corner of envelopes.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Dominique Pelle
> I've encountered a small annoyance in 7.2 (and earlier) in GNOME (and
> I've heard it's in KDE as well). If I click on the window manager's
> maximize button, it fills the screen rather nicely, but if I then add
> a tab, this resizes the window, pushing the bottom couple of lines off
> of the screen. Restoring and re-maximizing fixes this (of course),
> but if I ever go down below two tabs again and then add another, the
> same thing happens again. set showtabline=2 fixes the issue, but it's
> probably something you should know about anyway. My .gvimrc for
> reference:
The same kind of resize bug happens with gvim (GTK2 GUI) when doing this:
- start gvim with: gvim -u NONE -U NONE
- set a large font with :set gfn=Monospace\ 10
- Maximize gvim window by clicking on the window manager "maximize" button
- set a smaller font with :set gfn=Monospace\ 8
- observe that gvim window does not resize properly (elevator in the middle)
-- Dominique
Dominique Pelle
> 2008/10/17 Andy Walker:
Trying to experiment, I found that enabling 'resize_idle_installed'
in gui_gtk_x11.c fixes both resize problems when gvim (GTK2)
is maximized. I.e. gvim then resizes properly while maximized when:
- adding/deleting tabs;
- or when changing guitfont.
But the catch is that 'resize_idle_installed' was disabled (#if 0...)
because it broke something when doing "set lines+=1" according
to a comment in code. Doing a google search on 'resize_idle_installed',
I see that it was disabled a long time ago (Apr 2004) in patch 6.2.439
So re-enabling it may be a no-go. At least knowing this may help to
fix it in a better way.
Patch to re-enable 'resize_idle_installed':
$ cvs diff -c gui_gtk_x11.c
Index: gui_gtk_x11.c
===================================================================
RCS file: /cvsroot/vim/vim7/src/gui_gtk_x11.c,v
retrieving revision 1.61
diff -c -r1.61 gui_gtk_x11.c
*** gui_gtk_x11.c 28 Nov 2008 20:28:56 -0000 1.61
--- gui_gtk_x11.c 4 Dec 2008 04:41:36 -0000
***************
*** 4271,4277 ****
}
#ifdef HAVE_GTK2
! #if 0
static int resize_idle_installed = FALSE;
/*
* Idle handler to force resize. Used by gui_mch_set_shellsize() to ensure
--- 4271,4277 ----
}
#ifdef HAVE_GTK2
! #if 1
static int resize_idle_installed = FALSE;
/*
* Idle handler to force resize. Used by gui_mch_set_shellsize() to ensure
***************
*** 4357,4363 ****
else
update_window_manager_hints(width, height);
! #if 0
if (!resize_idle_installed)
{
g_idle_add_full(GDK_PRIORITY_EVENTS + 10,
--- 4357,4363 ----
else
update_window_manager_hints(width, height);
! #if 1
if (!resize_idle_installed)
{
g_idle_add_full(GDK_PRIORITY_EVENTS + 10,
-- Dominique
Bram Moolenaar
Dominique Pelle wrote:
The GTK resizing is messed up. There have been several attempts to fix
this, but none of them have caught all the problems. One of the things
that make it hard to fix are the race conditions involved. When using a
debugger to step through the code you can't reproduce problems
encountered in real time. For the last fix I did I concatenated events
to a variable and display it after the action is finished. That's
cumbersome, but does give the correct info.
Hopefully someone who understands these details about GTK and
understands what Vim is doing will dig into it and come up with a nice
solution.
I don't think it's a good idea to re-enable this code without fully
understanding why it was disabled.
--
ARTHUR: What?
BLACK KNIGHT: None shall pass.
ARTHUR: I have no quarrel with you, good Sir knight, but I must cross
this bridge.
BLACK KNIGHT: Then you shall die.
The Quest for the Holy Grail (Monty Python)