On 27/07/11 09:53, Tobbe Lundberg wrote:
On Wednesday, July 27, 2011 2:44:56 AM UTC+2, Tony Mechelynck wrote:

 > The problem with GUI window splitters is that they would still have to
 > be exactly the width of one character cell in the current 'guifont'
 > whatever it be,

Can you expand on this? Why does it need to be that wide?

Because of the constraints of the fixed-size character cell. The whole Vim screen is like a sort of grid with cells all the same size: most characters use one cell, CJK-wide use two cells, hard tabs use between one and 'tabstop' cells, unprintable characters may use two, four, six etc.: ^M <9c> <feff>, but always an integer number.

When windows are split, the split does not necessarily span the whole height or width of the screen: it can very well be like this (fixed font please):

 ---------------------------------------------------
|                                                   |
|                                                   |
|                           Window 1                |
|                                                   |
|statusline 1=======================================|
|                       |                           |
|                       |                           |
|      Window 2         |                           |
|                       |                           |
|statusline 2===========|      Window 4             |
|                       |                           |
|      Window 3         |                           |
|                       |                           |
|statusline 3===========|statusline 4===============|
|command-line area                                  |
|___________________________________________________|

which must fit within the "grid", so, because of the T-joinings, the width of the vertical split and the height of the horizontal split have to be exactly one (or a multiple of one, but the current value is one) character cell width or height respectively.


I was hoping this wouldn't be a fundamental change, but rather
something that would just enhance the look of gvim. (Possibly (at
least at first) at the cost of not being compatible with all
plugins/scripts (like those using the status line))

Beckwards incompatibility is a no-no; if I know Bram he will never allow it except for much more serious a reason than just "it would look better". Maybe you don't use a custom status line BTW, but I do, and I'm far from being the only user who does.


 > Yes, in some respects Vim is a kind of dinosaur; I think that it
 > descends in straight line from editors which were used on systems where
 > you had no screen but a typewriter which could move the paper in one
 > direction only, no other keyboard than a plain typewriter keyboard, and
 > no mouse; and it is still quite feasible to use Vim without using the
 > mouse or the keyboard's cursor movement keys at all (and some old Vim
 > hands will tell you that _that_ is the "true" way to use Vim, indeed the
 > "only right way"; I don't go that far); but with all its
 > old-fashionedness it is still (IMHO) one of the very best, possibly
 > *the* best plain-text editor for the 21st century.

The thing is that making gvim more modern wouldn't take away any of
that. You still have the option of using vim (i.e. in a terminal)

You mean I could not use gvim anymore the way I like it, with custom statusline and text-style tabs, but also any installed monospace font I damn well please? That's certainly a no-no. Any controversial chyange should be optional.


 > Best regards,
 > Tony.
--
An idea is not responsible for the people who believe in it.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Reply via email to