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
No comments:
Post a Comment