size of gvim window on WIN32

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

size of gvim window on WIN32

Hans-5
hello,

        I'm used to opening files with GVim with right click menu.
The default GVim windows seems a little narrow to me. I always
use mouse to drag and drop to resize the GVim window.
        Is there any smart way?

THX.

Yorkwar
20050929

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Edward L. Fox
Hi Yorkwar,

You can put these command into your .vimrc

set lines=50
set columns=120


Regards,

Edward L. Fox

在 05-9-29,Yorkwar<[hidden email]> 写道:

> hello,
>
>         I'm used to opening files with GVim with right click menu.
> The default GVim windows seems a little narrow to me. I always
> use mouse to drag and drop to resize the GVim window.
>         Is there any smart way?
>
> THX.
>
> Yorkwar
> 20050929
>
>
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Dominic Evans
I prefer my vim window to be at the default size if i'm only editing
one file. However if I've asked vim to open more than one file in a
split (-o or -O) i'd like the window to open at a larger size to
acommodate the multiple windows. Is there any way to do that?

Cheers,
Dom

On 29/09/05, Edward L. Fox <[hidden email]> wrote:

> Hi Yorkwar,
>
> You can put these command into your .vimrc
>
> set lines=50
> set columns=120
>
>
> Regards,
>
> Edward L. Fox
>
> 在 05-9-29,Yorkwar<[hidden email]> 写道:
> > hello,
> >
> >         I'm used to opening files with GVim with right click menu.
> > The default GVim windows seems a little narrow to me. I always
> > use mouse to drag and drop to resize the GVim window.
> >         Is there any smart way?
> >
> > THX.
> >
> > Yorkwar
> > 20050929
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Hans-5
Yorkwar wrote:

> hello,
>
> I'm used to opening files with GVim with right click menu.
> The default GVim windows seems a little narrow to me. I always
> use mouse to drag and drop to resize the GVim window.
> Is there any smart way?
>
> THX.
>
> Yorkwar
> 20050929
>
>
>
>
see
        :help :winpos
        :help 'lines'
        :help 'columns'

The size (in inches or pixels) of the gvim windows depends both on
'lines' times 'columns' and on the size of the character cell defined by
the 'guifont', so when you change the font, the window will usually
change size.

For instance, to maximize the gvim window on startup, put the following
in your vimrc (or in your gvimrc, but I don't use the latter):

if has("gui_running")
        set guifont=whatever
        set lines=99999 columns=99999
endif

Replace "whatever" by whatever 'guifont' setting you use, of course. If
the GUI is not yes started (e.g., if set in the vimrc) the settings are
remembered until it does start.


HTH,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Dominic Evans
Dominic Evans wrote:
> I prefer my vim window to be at the default size if i'm only editing
> one file. However if I've asked vim to open more than one file in a
> split (-o or -O) i'd like the window to open at a larger size to
> acommodate the multiple windows. Is there any way to do that?
>
> Cheers,
> Dom

        if (has("gui_running") && (winnr("$") > 1)
                set lines=99999 columns=99999
        endif


see ":help winnr()"

I put in the test on has("gui_running") because it is a dubious idea to
try resizing the console window: some console windows can be resized,
others can't, and those who can may sometime give problems later if you
invoke some external programs from Vim.


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Dominic Evans
Hi,

I'm afraid this doesn't work for me, the gui still seems to open at
standard size.

I also found a bug, its probably in vim6 as well but I was running
vim7 alpha build. There doesn't seem to be any range checking done on
the columns variable. So if it overflows it crashes vim.

:set columns=999999999

Cheers,
Dom

On 29/09/05, A. J. Mechelynck <[hidden email]> wrote:

> Dominic Evans wrote:
> > I prefer my vim window to be at the default size if i'm only editing
> > one file. However if I've asked vim to open more than one file in a
> > split (-o or -O) i'd like the window to open at a larger size to
> > acommodate the multiple windows. Is there any way to do that?
> >
> > Cheers,
> > Dom
>
>         if (has("gui_running") && (winnr("$") > 1))
>                 set lines=99999 columns=99999
>         endif
>
>
> see ":help winnr()"
>
> I put in the test on has("gui_running") because it is a dubious idea to
> try resizing the console window: some console windows can be resized,
> others can't, and those who can may sometime give problems later if you
> invoke some external programs from Vim.
>
>
> Best regards,
> Tony.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Robert Cussons
I could be wrong, but I would guess that this is to do with the size of the
variable columns is stored in, i.e. if it is an int, there will be a limited
amount of storage space and if you exceed it, the number stored is undefined
or nonsense. Therefore, when you start vim it probably doesn't know what to
do. If this is true I'm not sure whether it counts as a bug beacuse I
wouldn't think this is a good way of setting size, finding the correct
maximised dimensions and inputting them would be better, or maybe it is a bug
and Vim should do that itself automatically if you exceed the maximum
dimensions.....

On Thursday 29 September 2005 11:39, Dominic Evans wrote:

> Hi,
>
> I'm afraid this doesn't work for me, the gui still seems to open at
> standard size.
>
> I also found a bug, its probably in vim6 as well but I was running
> vim7 alpha build. There doesn't seem to be any range checking done on
> the columns variable. So if it overflows it crashes vim.
>
> :set columns=999999999
>
> Cheers,
> Dom
>
> On 29/09/05, A. J. Mechelynck <[hidden email]> wrote:
> > Dominic Evans wrote:
> > > I prefer my vim window to be at the default size if i'm only editing
> > > one file. However if I've asked vim to open more than one file in a
> > > split (-o or -O) i'd like the window to open at a larger size to
> > > acommodate the multiple windows. Is there any way to do that?
> > >
> > > Cheers,
> > > Dom
> >
> >         if (has("gui_running") && (winnr("$") > 1))
> >                 set lines=99999 columns=99999
> >         endif
> >
> >
> > see ":help winnr()"
> >
> > I put in the test on has("gui_running") because it is a dubious idea to
> > try resizing the console window: some console windows can be resized,
> > others can't, and those who can may sometime give problems later if you
> > invoke some external programs from Vim.
> >
> >
> > Best regards,
> > Tony.

--
================================
Robert Cussons
Office SB3 3.163, Theory Group
Gesellschaft für Schwerionenforschung mbH (GSI)
Planckstraße 1
64291 Darmstadt
Germany.

Tel: +49 (0)6159 71 2754
E-mail: [hidden email]
================================
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Dominic Evans
Well yes it 99.9% is the fact that the variable is stored in say an
int and its overflowing.

But vim should have:

if (columns > MAX_INT)
    columns = MAX_INT

Rather than just crashing :)

Cheers,
Dom

On 29/09/05, Robert Cussons <[hidden email]> wrote:

> I could be wrong, but I would guess that this is to do with the size of the
> variable columns is stored in, i.e. if it is an int, there will be a limited
> amount of storage space and if you exceed it, the number stored is undefined
> or nonsense. Therefore, when you start vim it probably doesn't know what to
> do. If this is true I'm not sure whether it counts as a bug beacuse I
> wouldn't think this is a good way of setting size, finding the correct
> maximised dimensions and inputting them would be better, or maybe it is a bug
> and Vim should do that itself automatically if you exceed the maximum
> dimensions.....
>
> On Thursday 29 September 2005 11:39, Dominic Evans wrote:
> > Hi,
> >
> > I'm afraid this doesn't work for me, the gui still seems to open at
> > standard size.
> >
> > I also found a bug, its probably in vim6 as well but I was running
> > vim7 alpha build. There doesn't seem to be any range checking done on
> > the columns variable. So if it overflows it crashes vim.
> >
> > :set columns=999999999
> >
> > Cheers,
> > Dom
> >
> > On 29/09/05, A. J. Mechelynck <[hidden email]> wrote:
> > > Dominic Evans wrote:
> > > > I prefer my vim window to be at the default size if i'm only editing
> > > > one file. However if I've asked vim to open more than one file in a
> > > > split (-o or -O) i'd like the window to open at a larger size to
> > > > acommodate the multiple windows. Is there any way to do that?
> > > >
> > > > Cheers,
> > > > Dom
> > >
> > >         if (has("gui_running") && (winnr("$") > 1))
> > >                 set lines=99999 columns=99999
> > >         endif
> > >
> > >
> > > see ":help winnr()"
> > >
> > > I put in the test on has("gui_running") because it is a dubious idea to
> > > try resizing the console window: some console windows can be resized,
> > > others can't, and those who can may sometime give problems later if you
> > > invoke some external programs from Vim.
> > >
> > >
> > > Best regards,
> > > Tony.
>
> --
> ================================
> Robert Cussons
> Office SB3 3.163, Theory Group
> Gesellschaft für Schwerionenforschung mbH (GSI)
> Planckstraße 1
> 64291 Darmstadt
> Germany.
>
> Tel: +49 (0)6159 71 2754
> E-mail: [hidden email]
> ================================
>
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Dominic Evans
s/MAX_INT/INT_MAX/

:)

2147483647 is the last value at which the window just stays maximised,
after that we start getting overflow and the window either just goes
to its smallest possible size (columns=20 i think) or vim crashes

On 29/09/05, Dominic Evans <[hidden email]> wrote:

> Well yes it 99.9% is the fact that the variable is stored in say an
> int and its overflowing.
>
> But vim should have:
>
> if (columns > MAX_INT)
>     columns = MAX_INT
>
> Rather than just crashing :)
>
> Cheers,
> Dom
>
> On 29/09/05, Robert Cussons <[hidden email]> wrote:
> > I could be wrong, but I would guess that this is to do with the size of the
> > variable columns is stored in, i.e. if it is an int, there will be a limited
> > amount of storage space and if you exceed it, the number stored is undefined
> > or nonsense. Therefore, when you start vim it probably doesn't know what to
> > do. If this is true I'm not sure whether it counts as a bug beacuse I
> > wouldn't think this is a good way of setting size, finding the correct
> > maximised dimensions and inputting them would be better, or maybe it is a bug
> > and Vim should do that itself automatically if you exceed the maximum
> > dimensions.....
> >
> > On Thursday 29 September 2005 11:39, Dominic Evans wrote:
> > > Hi,
> > >
> > > I'm afraid this doesn't work for me, the gui still seems to open at
> > > standard size.
> > >
> > > I also found a bug, its probably in vim6 as well but I was running
> > > vim7 alpha build. There doesn't seem to be any range checking done on
> > > the columns variable. So if it overflows it crashes vim.
> > >
> > > :set columns=999999999
> > >
> > > Cheers,
> > > Dom
> > >
> > > On 29/09/05, A. J. Mechelynck <[hidden email]> wrote:
> > > > Dominic Evans wrote:
> > > > > I prefer my vim window to be at the default size if i'm only editing
> > > > > one file. However if I've asked vim to open more than one file in a
> > > > > split (-o or -O) i'd like the window to open at a larger size to
> > > > > acommodate the multiple windows. Is there any way to do that?
> > > > >
> > > > > Cheers,
> > > > > Dom
> > > >
> > > >         if (has("gui_running") && (winnr("$") > 1))
> > > >                 set lines=99999 columns=99999
> > > >         endif
> > > >
> > > >
> > > > see ":help winnr()"
> > > >
> > > > I put in the test on has("gui_running") because it is a dubious idea to
> > > > try resizing the console window: some console windows can be resized,
> > > > others can't, and those who can may sometime give problems later if you
> > > > invoke some external programs from Vim.
> > > >
> > > >
> > > > Best regards,
> > > > Tony.
> >
> > --
> > ================================
> > Robert Cussons
> > Office SB3 3.163, Theory Group
> > Gesellschaft für Schwerionenforschung mbH (GSI)
> > Planckstraße 1
> > 64291 Darmstadt
> > Germany.
> >
> > Tel: +49 (0)6159 71 2754
> > E-mail: [hidden email]
> > ================================
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Bram Moolenaar
In reply to this post by Dominic Evans

Dominic Evans wrote:

> I'm afraid this doesn't work for me, the gui still seems to open at
> standard size.
>
> I also found a bug, its probably in vim6 as well but I was running
> vim7 alpha build. There doesn't seem to be any range checking done on
> the columns variable. So if it overflows it crashes vim.
>
> :set columns=999999999

I don't see a crash, but many bad things do happen.  Root problem is
that memory can't be allocated, the screen structure pointerss are NULL,
etc.

For Vim 7 I fixed a few side effects, such as not being able to type a
command.  It was actually stored right to left, since the cursor wasn't
advanced, quite strange.

I'll limit the value to 10000, that should avoid the trouble.  First in
Vim 7 and when this appears to work well I'll make a patch for Vim 6.3.

--
It is illegal for a driver to be blindfolded while operating a vehicle.
                [real standing law in Alabama, United States of America]

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Dominic Evans
Dominic Evans wrote:

> Hi,
>
> I'm afraid this doesn't work for me, the gui still seems to open at
> standard size.
>
> I also found a bug, its probably in vim6 as well but I was running
> vim7 alpha build. There doesn't seem to be any range checking done on
> the columns variable. So if it overflows it crashes vim.
>
> :set columns=999999999
>
> Cheers,
> Dom

Well, if it crashes gvim it's a bug. I suppose overflow checking (for
all numeric options) wouldn't be too hard a thing to do but I haven't
looked at the code. Could you produce a backtrace of the crash? Try
doing it with a debug build (i.e., gvimd.exe rather than gvim.exe) so
the backtrace will (hopefully) be easier to read for a human. If you can
reproduce the crash with a debug build, send your bug report (with the
backtrace) directly to Bram, I think he would be the man best able to
correct the problem.

In any case, 99999, or even 9999 or 999, should be enough to ensure that
the full width (or height) is used. gvim does check the value given
against the size of the viewport, so you will never get more lines or
columns than your screen is capable of handling. In some borderline
cases you may get just one less than what the "Maximize" menu item would
give you, but the discrepancy doesn't bother me overmuch.


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Robert Cussons
Robert Cussons wrote:
> I could be wrong, but I would guess that this is to do with the size of the
> variable columns is stored in, i.e. if it is an int, there will be a limited
> amount of storage space and if you exceed it, the number stored is undefined
> or nonsense. Therefore, when you start vim it probably doesn't know what to
> do. If this is true I'm not sure whether it counts as a bug beacuse I
> wouldn't think this is a good way of setting size, finding the correct
> maximised dimensions and inputting them would be better, or maybe it is a bug
> and Vim should do that itself automatically if you exceed the maximum
> dimensions.....


All numbers are stored as 32-bit signed integers, see ":help variable".
I think the problem happens when converting a String (which can be any
length) to a Number.

In addition, &lines and &columns cannot be made greater than the screen
size in the direction considered. They also have a minimum value but I'm
not sure what it is in practice. I think three lines (maybe two with
'laststatus' set to 0) and (how many?) maybe ten columns, oughtn't to be
more than the "practical" minimum.

Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Dominic Evans
Dominic Evans wrote:
> s/MAX_INT/INT_MAX/
>
> :)
>
> 2147483647 is the last value at which the window just stays maximised,
> after that we start getting overflow and the window either just goes
> to its smallest possible size (columns=20 i think) or vim crashes


That makes sense. That number is 2^31 - 1, or the biggest positive
number Vim can handle. Add one to that in hardware and you get
-214783648 with the overflow flag set.

The crash may be due to the number of columns becomig to small for Vim
to handle properly. I have had some crashes in the past when trying to
use a very big font size setting ("set gfn=Courier_new:h48:cDEFAULT"
maybe) in order to see the Arabic glyphs with enough detail. Of course,
with such a big font, the maximum possible number of lines & columns
becomes rather small...


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Dominic Evans
In reply to this post by A.J.Mechelynck
You're lucky im a programmer and know what to do :)

Backtrace attached for the interested. It will be fixed by the 'if
columns >' I mentioned earlier but I spose people may still want to
know where the bug itself actually occurs.

Cheers,
Dom

On 30/09/05, A. J. Mechelynck <[hidden email]> wrote:

> Dominic Evans wrote:
> > Hi,
> >
> > I'm afraid this doesn't work for me, the gui still seems to open at
> > standard size.
> >
> > I also found a bug, its probably in vim6 as well but I was running
> > vim7 alpha build. There doesn't seem to be any range checking done on
> > the columns variable. So if it overflows it crashes vim.
> >
> > :set columns=999999999
> >
> > Cheers,
> > Dom
>
> Well, if it crashes gvim it's a bug. I suppose overflow checking (for
> all numeric options) wouldn't be too hard a thing to do but I haven't
> looked at the code. Could you produce a backtrace of the crash? Try
> doing it with a debug build (i.e., gvimd.exe rather than gvim.exe) so
> the backtrace will (hopefully) be easier to read for a human. If you can
> reproduce the crash with a debug build, send your bug report (with the
> backtrace) directly to Bram, I think he would be the man best able to
> correct the problem.
>
> In any case, 99999, or even 9999 or 999, should be enough to ensure that
> the full width (or height) is used. gvim does check the value given
> against the size of the viewport, so you will never get more lines or
> columns than your screen is capable of handling. In some borderline
> cases you may get just one less than what the "Maximize" menu item would
> give you, but the discrepancy doesn't bother me overmuch.
>
>
> Best regards,
> Tony.
>
>

backtrace.txt (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

Bram Moolenaar

Dominic Evans wrote:

> You're lucky im a programmer and know what to do :)
>
> Backtrace attached for the interested. It will be fixed by the 'if
> columns >' I mentioned earlier but I spose people may still want to
> know where the bug itself actually occurs.

Thanks.  The recursive call to gui_mch_draw_string() is the problem.
I'll avoid it by calling lalloc() instead of alloc(), so that no "out of
memory" message is given when trying to display the same message.

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: size of gvim window on WIN32

A.J.Mechelynck
In reply to this post by Dominic Evans
Dominic Evans wrote:
> You're lucky im a programmer and know what to do :)
>
> Backtrace attached for the interested. It will be fixed by the 'if
> columns >' I mentioned earlier but I spose people may still want to
> know where the bug itself actually occurs.
>
> Cheers,
> Dom

Thanks. Though apparently Bram was able to reproduce the error and fix
it even before I saw your post below (I'm a little backward in ML
answering at the moment).

Best regards,
Tony.

>
> On 30/09/05, A. J. Mechelynck <[hidden email]> wrote:
>> Dominic Evans wrote:
>>> Hi,
>>>
>>> I'm afraid this doesn't work for me, the gui still seems to open at
>>> standard size.
>>>
>>> I also found a bug, its probably in vim6 as well but I was running
>>> vim7 alpha build. There doesn't seem to be any range checking done on
>>> the columns variable. So if it overflows it crashes vim.
>>>
>>> :set columns=999999999
>>>
>>> Cheers,
>>> Dom
>> Well, if it crashes gvim it's a bug. I suppose overflow checking (for
>> all numeric options) wouldn't be too hard a thing to do but I haven't
>> looked at the code. Could you produce a backtrace of the crash? Try
>> doing it with a debug build (i.e., gvimd.exe rather than gvim.exe) so
>> the backtrace will (hopefully) be easier to read for a human. If you can
>> reproduce the crash with a debug build, send your bug report (with the
>> backtrace) directly to Bram, I think he would be the man best able to
>> correct the problem.
>>
>> In any case, 99999, or even 9999 or 999, should be enough to ensure that
>> the full width (or height) is used. gvim does check the value given
>> against the size of the viewport, so you will never get more lines or
>> columns than your screen is capable of handling. In some borderline
>> cases you may get just one less than what the "Maximize" menu item would
>> give you, but the discrepancy doesn't bother me overmuch.
>>
>>
>> Best regards,
>> Tony.
[...]