Obviously this calculation cannot be done consistantly, so it seems like a lousy idea. The user should be allowed to specify the geometry!
--
MK <halfco...@intergate.com>
I fought with this on Win32 gvim and never found a satisfactory
solution...Vim regularly wanted to override the specified number
of lines to make sure it fit on the screen for its definition of
"fit" (which, as you experience, left several lines off). I've
since moved mostly to my Linux box where I use console vim
instead, and have my xterms set so that I can maximize them
vertically with no window-chrome (fairly easy to do in
Fluxbox...not sure about other window managers).
-tim
Fvwm will do that -- which is how I've had it for long time -- fullscreen terminal with no frame. But I've been feeling the need for mouse funtionality and tabs. Maybe I have to go back, because get this: it does the same thing when you open a new tab (resizes!).
That's two of us. I'm gonna find out where to file a ticket. This is just plain a very very stupid feature. I wonder if it's cause Bram always uses a terminal too :P
--
MK <halfco...@intergate.com>
Is there any way to prevent vim from auto-resizing? It will not accept any value higher than 41 for height -- I imagine this is calculated with the font, etc. Anyway, it is extremely irritating since I then have to pull the bottom down another two lines (ie, the window border is still visible at 43 lines).
I don't know whether this is relevant to your setup or the resizing
issue, but you can use non-graphical tabs within gvim. Just remove "e"
from :set guioptions. Then tabs will display as they do in plain vim.
(they're much nicer looking this way, imo) I'm not noticing the
resizing behavior with the graphical tabs on Windows though.
-BC
I don't think it's stupid. Without it, ":set lines=999 columns=999"
would make gvim really set its screen to 999 lines by 999 columns, with
most of it hidden from view (off your display screen), including the
command-line. (Actually, that's what happens if you issue this command
when gvim is already maximized.)
If you're on X11, then maybe you have 'guiheadroom' (q.v.) set otherwise
than you'd like it (the default is 50 pixels, I use zero, it can even be
made negative).
Here, ":set lines=999 columns=999" pretty much maximizes gvim, with
maybe half a character cell's height left at the bottom and a pixel or
two at far right. If you want to make it fit tightly (with any partial
character-cell height or width inside the gvim screen rather than
outside it), you can "Maximize" gvim using OS controls (like the
square-like icon near one end of the titlebar, or the Maximize menuitem
in the System menu). If it doesn't work the first time (i.e. if it
doesn't really maximize the window), do it again immediately.
On Windows, but not on other platforms, you can trigger that menu by
means of the :simalt command (see ":help :simalt") if you know what
letter corresponds to Maximize in the menu language used by the version
of Windows on which gvim is running: in English versions it would be
":simalt ~x" (without the quotes), but there are languages where the
equivalent of Maximize does not correspond to x (I remember that "File"
is "Bestand" in Dutch and "Datei" in German, but I don't remember how
either of these languages says "Maximize").
On X11, at least some versions of gvim accept a -geometry argument, see
":help -geometry-example" (linked to from ":help -geometry"). This
argument is not recognized by non-X11 versions of gvim, though.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
256. You are able to write down over 250 symptoms of being an internet
addict, even though they only asked for 101.
If Vim offered a true maximize function, and/or allowed a
special value such as "-1" to be used for lines/columns to
mean "as much as Vim thinks should be allowed" (the current
clipping maximum when 999 is used), it would solve a
repeated hacks that Tony describes. When the topic comes up
on the list, the answers are to either
1) use "set lines=999 columns=999" but vim may
mis-approximate your dimensions and rob you of a row or two
(as you and I are experiencing)
2) use simalt but it's non-portable across platforms and
locales as Tony warns
I think my biggest frustration on the issue is that there's
no way to say "use my value and I bloody mean it, don't try
to clip to some arbitrary value you think will fit on the
screen". You can drag the resize corners of gvim (or the
console corner around a console vim) and exceed the caps for
lines/columns, but you can't set them explicitly to those
values and restore where you previously were.
I've actually had cases on Win32 where I resized by
dragging the corner of gvim to be *truly maximized* and then
clicked on the "maximize" button and *lost* lines (about 2
lines went away). There's something wrong when this
happens.
-tim