On Jul 26, 7:44 pm, Tony Mechelynck <[email protected]> wrote: > On 27/07/11 00:26, Tobbe Lundberg wrote: > > > Does anyone know of any attempts at making gvim (for MS Windows) look > > more modern? (Using a standard gui border for split windows, a > > gui-window for completion lists, a standard gui status bar, etc) > > > If something like this doesn't already exist, would anyone be interested > > in me tying to code it? (Possibly even helping me out?) It would > > probably have to be maintained as a set of patches against the official > > vim releases.
I certainly would be interested in a nicer-looking GUI for the split windows and completion lists, but I LIKE the status bar the way it is. I agree that Vim looks very out of place in a modern system. Other editors have split window functionality these days and frankly, it looks a lot better. The Fold Column could also use a nice-looking GUI, again to bring it up-to-par with the Folding which now exists in other editors as well. > > 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, and for horizontal splitters, either of negligible > height, or just high enough to include a GUI-style "Vim status line" > which (for alignment between parts of various windows' status lines) may > still have to be in a monospace font, probably the current 'guifont'. > Otherwise I think it would not be possible without rewriting all of gvim > from the ground up, and I don't think that this kind of code forking > (compared to console Vim) is desirable, let alone humanly possible. > I don't think this would be hard. I think the way to do things, would be to add empty "buffer" space which is not a full character, around the bottom and right edges of each split window, or do whatever is currently done to make gvim take up the whole display when maximized. Screen displays are certainly not always integer multiples of a character cell in dimension. Resizing split windows could be done with normal GUI widgets, and the window itself would still use an integer multiple of character cells, possibly with some small unused space between the last line/column and the divider. The statusline could just always be drawn in the last line of the window, if it is present. If buffer space is needed, it would be highlighted with the same bg colors as the last line (which could be a statusline) so the change in appearance of the window text would be small. Alternatively, the statusline could be "attached" to the splitter. The buffer space could either be at the top of the statusline, or for less logic in the code, it could just be on the last text line always. I'm not sure which approach is easier, and I'm not certain what Vim does to fill the screen when maximized, but I don't think it would be that hard to substitute a GUI splitter for the vertical window separator, with the window contents adjusting to fit, and to add a GUI splitter to the bottom of the statusline/horizontal separator. > If you don't like the default look and feel of gvim, it is already > possible to change it quite a lot by changing the 'guifont' and the > colorscheme (and if none of the available schemes find favour in your > eyes, you can always write your own, it is infinitely easier than > patching the C/C++ code, and unlike the latter it runs no risk of making > the program nonfunctional or even crashy). > Changing font and colorscheme does not change the "look and feel" of the editor. It changes a decent amount of the "look", but Vim is still very out-of-place among other GUI applications. It looks like I'm running a terminal, not a GUI application. > In my experience, most proposals to change Vim's or gvim's behaviour > fundamentally (as opposed to extending its power, as was done in the > past with adding a GUI, menus, (partial) support for RTL scripts, > support of Unicode, tab pages, etc., without changing anything to > existing functionality) come from users who have not yet imbibed Vim's > "philosophy". Vim is different from other programs, sometimes quite > different, even in respects where they are all more or less "alike". The > solution is not to twist Vim out of shape to make it "like all the > others", but rather to learn Vim as something different (and there is > quite a lot to be learned about it; I regard that as a quality, not a > blemish, even though I am far from having mastered all aspects of Vim > perfectly) and to find out how these differences can make you perform > your editing tasks more efficiently. > I certainly like Vim's behavior. I wouldn't want to change that. I don't consider the addition of GUI elements a "fundamental" change. Vim added tab-page support in version 7, and although there are certainly complaints, I doubt it "fundamentally" altered any behavior. If Vim adds GUI split windows, etc. I fully expect them to act differently than in other applications. After all, Vim's tab pages differ significantly from most applications' concept of a tab for tabbed editing, and I LIKE the extra flexibility Vim added in this area. Using a GUI for window splits or popup windows or even the Fold Column (which I would actually like to see far more than the popup, which is acceptable in its current form to me) would hardly be a bigger change than tab pages. Certainly I would expect adding such GUI elements would probably be done in a new minor (or even major) version number, either 7.4, 7.5, or even 8.0. > 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. > I couldn't agree more. But Vim could certainly receive a facelift without losing its usefulness. Sadly, I really don't know enough about coding a GUI to help much with actually implementing this. But I'd like to see it done, if it didn't mess up the functionality I know and love! -- 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
