On Thursday, July 28, 2011 7:21:19 AM UTC+2, Tony Mechelynck wrote: > 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): [Graphic omitted] > > 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.
The GUI splitters could be padded with empty pixels to make them exactly one* character cell wide/tall. You'd get the modern look, but the same size as they have always been. (*) Using a tiny guifont might make one character cell narrower than a GUI window splitter. Would it be acceptable to make the splitter use exactly two character cells in this case? > Backwards 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, I figured this was the case. I do use a custom status line, but personally I would be willing to give it up for a standard GUI status bar. A few people have raised their concerns for the status line now. I see a few possible solutions. 1. Keep the status bar exactly as it is. I think this is the only way to be 100% backwards compatible. 2. Create a GUI statusbar, but make it just an empty field and write whatever the user has set as "statusline" in it. Will probably have to use a smaller/different font than guifont to make everything fit. 3. Create a GUI statusbar with support for dividing it up in different fields. It would use a special syntax for configuring it, for example using the pipe character (|) to specify a new field. (The gui status bar is raised by default, a field is a sunken part of the status bar, giving it borders all around.) Option 2 and 3 can probably be combined. So the best option is probably to implement both 1 and 2/3, and then let the user choose which one he/she prefers. > 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 > change should be optional. No, that is not what I mean. But you are not the only one who understood it that way, so I must have expressed myself poorly. What I meant was that you could still use vim on ancient machines with "no other keyboard than a plain typewriter keyboard, and no mouse" or machines with only a terminal. I.e. you can still use vim where vim has always been the only option. Gvim will still be usable in any setting it has previously been usable. See above for my proposal for the status line. Of course you will be able to pick any monospaced font you want for the editor. What do you mean by "text-style tabs"? -- 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
