On Thu, 28 Jul 2011, Tony Mechelynck wrote:
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.
This doesn't mean that the GUI splitters themselves need to be a
multiple of the character width/height. Right now I'm using
rxvt-unicode where the character cell dimensions don't evenly divide the
terminal window's dimensions. So there are slight "dead zone" borders
on the right and bottom sides of the window. In modifying GVim to look
more modern, it could just accommodate that type of bordering in each
window.
Expanding your example, here's what I mean. Disregard the text atop the
status lines (which might be a different font anyway), and imagine the
font is such that it takes four cells per character. Then the shaded
areas below are these "dead zones" where a full character can't appear,
so a border is drawn instead:
┌───────────────────────────────────────────────────┐
│T┐h┐i┐s┐ ┐i┐s┐ ┐w┐h┐a┐t┐ ┐I┐'┐m┐ ┐t┐a┐l┐k┐i┐n┐g┐ ┐░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
│a┐b┐o┐u┐t┐.┐ ┐T┐h┐e┐ ┐w┐i┐n┐d┐o┐w┐s┐ ┐h┐a┐v┐e┐ ┐b┐░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
├statusline 1───────────┬───────────────────────────┤
│o┐r┐d┐e┐r┐s┐ ┐t┐h┐a┐t┐░│t┐c┐h┐e┐d┐ ┐d┐i┐m┐e┐n┐s┐i┐░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
│ ┐a┐c┐c o m m o d a t┐░│o┐n┐s┐ ┐o┐f┐ ┐t┐h┐e┐ ┐c┐e┐░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
├statusline 2───────────┤l┐l┐s┐ ┐a┐n┐d┐ ┐t┐h┐e┐ ┐s┐░│
│e┐ ┐t┐h┐e┐ ┐m┐i┐s┐m┐a┐░│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│c┐r┐e┐e┐n┐.┐ ┐ ┐ ┐ ┐ ┐ ┐ ┐░│
│░░░░░░░░░░░░░░░░░░░░░░░│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
│statusline 3───────────┴statusline 4───────────────┤
│c┐o┐m┐m┐a┐n┐d┐-┐l┐i┐n┐e┐ ┐a┐r┐e┐a┐ ┐ ┐ ┐ ┐ ┐ ┐ ┐ ┐░│
│└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘└┘░│
└───────────────────────────────────────────────────┘
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)
This seems the wrong stance to me. Changing the look of Gvim shouldn't
affect its functionality. While I generally use vim (not gvim), I've
considered switching, just for the undercurl decoration. The reason
it'd be easy to switch is pretty straightforward: GVim still behaves
(AFAICT) exactly the same as console vim. Only the appearance is
different.
--
Best,
Ben
--
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
