A modern look for gvim (win23)
Tobbe Lundberg
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.
//Tobbe
Tony Mechelynck
Good luck! :-/
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.
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).
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.
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.
Best regards,
Tony.
--
Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly.
Steve Hall
As the author of Cream, I'm very interested in gVim having a few more
OS-standard widgets. Tony has already written an excellent post
summarizing the arguments against. I'll take a shot at a few arguments
for.
1. With just a few widgets, gVim *could* be customized to look and
behave like many other editors designed within the current OS
Desktop paradigm. Having similar appearance to other text editors
at least keeps Vim from appearing inferior or antiquated to the
uninitiated.
2. Outrageous amounts of effort have gone into developing GUI
interfaces over the decades. They have stuck because they work on
many levels. You would be hard-pressed to sell machines these days
without a graphic input device (mouse or finger), GUI windows,
widgets, proportional fonts, etc. Even gVim has conceded to
toolbars, a statusline, scroll bars, tabs, dialog boxes,
highlighting and colored syntax, spelling indications, etc. Visual
conventions have developed because they make interfaces easier.
3. There are broader types of text editor usage that these
developments would assist beyond traditional Vim usage. Not all of
us simply use a text editor for 12 hours of coding. Some of us also
write content, display complex file states, or use applications to
minimally format or process information, etc. In those cases,
proportional fonts are more easily read, GUI statusbars could be
interactive, and dialog selection lists, radio buttons, etc. are
more flexible for displaying data and obtaining user input.
4. Non-refocusing find/replace dialogs are crazy. :)
Arguments against modern interface conventions make sense only in
situations of demonstrated need: terminals, editing over slow
connections, ancient hardware, etc. These are not the requirements for
99.9% of computer users. But Vi/Vim has always served those
capacities, it doesn't make sense that it suddenly abandon these
services. So I think there are some obvious requirements for improved
GUI features:
1. Not at the expense of existing features. (This in itself is no
hurdle, Vim has a terrific set of compile-time features.)
2. Multiple platform implementation. Windows-only doesn't cut it. Many
Vim users need similar features across at least Windows and
Linux/Gnome/GTK. (There are lots of single-OS editors out there
already.)
3. Self-motivated developer(s). Given the current expectations of the
community, there won't be much support for advanced GUI features.
There won't be much opposition if they meet the above requirements,
but implementation will require ownership and attention to detail
to ensure they work well and bug-free.
4. Tiny scopes. I would recommend implementing each GUI feature
independently of the others. A special library for everything is
too hard to write, control and patch. Use conventions like
+gui_statusbar, +gui_dialog_-widgets, and +font_prop. By
implementing features in small steps, they can be developed and
tested more quickly.
Obviously, I don't speak for the Vim community or its author. I'm just
an interested party who has been around for a few years. I've seen
these interests come and go, and would like to see some developments
exactly in line with what you've suggested.
--
Steve Hall [ digitect dancingpaper com ]
Tobbe Lundberg
> 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,
> 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
from the 80s
> In my experience, most proposals to change Vim's or gvim's behaviour
> fundamentally
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))
> 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.
that. You still have the option of using vim (i.e. in a terminal)
> Best regards,
> Tony.
Tobbe Lundberg
> As the author of Cream, I'm very interested in gVim having a few
> more OS-standard widgets.
> 1. With just a few widgets, gVim *could* be customized to look ...
> 2. Outrageous amounts of effort have gone into developing GUI ...
> 3. There are broader types of text editor usage that these ...
> 4. Non-refocusing find/replace dialogs are crazy. :)
> 2. Multiple platform implementation. Windows-only doesn't cut it.
> Many Vim users need similar features across at least Windows and
> Linux/Gnome/GTK. (There are lots of single-OS editors out there
> already.)
I'm personally in need of. But a GTK implementation would absolutely
be a good thing to have! And while I agree that there are a lot of
single-OS editors, there is none that I have found that is as good as
or better than vim for a lot of tasks, so a single-OS implementation
of a more modern gui for gvim would still have its merits.
> 3. Self-motivated developer(s). Given the current expectations of
> the community, there won't be much support for advanced GUI
> features.
> but implementation will require ownership and attention to
> detail to ensure they work well and bug-free.
> 4. Tiny scopes. I would recommend implementing each GUI feature
> independently of the others. A special library for everything is
> too hard to write, control and patch. Use conventions like
> +gui_statusbar, +gui_dialog_-widgets, and +font_prop. By
> implementing features in small steps, they can be developed and
> tested more quickly.
> --
> Steve Hall [ digitect dancingpaper com ]
Marko Mahnič
> 4. Tiny scopes. I would recommend implementing each GUI feature
> independently of the others. A special library for everything is
> too hard to write, control and patch. Use conventions like
> +gui_statusbar, +gui_dialog_-widgets, and +font_prop. By
> implementing features in small steps, they can be developed and
> tested more quickly.
>
2606). The first version was developed in Python. This year I ported
it to (object-oriented) C. Unfortunately after 3 months of porting and
about 7k lines of ooc I ran out of time, so the project is on hold.
The code is here:
http://code.google.com/r/markomahnic-vim-popuplist/
branch vim-popuplist, popuplst.c and included files.
Currently it uses the Vim internal drawing functions (vim screen). The
idea was to create interfaces for other GUI systems by reimplementing
the "virtual functions" of the PopupList "class".
I think that with some more work and some Vim Script it could also be
turned into a dialog system for text mode with the basic widgets
displayed as list items: label, button, radio button, line edit, check
box, drop-down list. This way one could write scripts that use GUI
dialogs that would be usable in GVim and in console Vim.
Marko
Marko Mahnič
screen.c . There are a lot of global structures that are used across
multiple files. There is a lot of code that is compiled conditionally
and adding GUI windows would add many more such pieces of code unless
the Vim code is rewritten using a more object-oriented approach.
So I think that it would be a huge undertaking just to change the
current windows to GUI windows.
Marko
Steve Hall
> On Wednesday, July 27, 2011 4:17:35 AM UTC+2, Steve wrote:
> >
> > As the author of Cream, I'm very interested in gVim having a few
> > more OS-standard widgets.
>
> How interested? Interested enough to help me implement it?
Unfortunately I can't write C which is at least 98% of the project. :)
But I'd happily contribute vimscript, test builds, bash scripts,
graphics, and whatever else might be useful. (I've put 10 years of
this on Cream.)
> > 2. Multiple platform implementation. Windows-only doesn't cut it.
> > Many Vim users need similar features across at least Windows and
> > Linux/Gnome/GTK.
>
> Windows is my only desktop OS, so that's the only implementation that
> I'm personally in need of. But a GTK implementation would absolutely
> be a good thing to have!
Finding an interested developer will be important.
> > 3. Self-motivated developer(s). Given the current expectations of
> > the community, there won't be much support for advanced GUI
> > features.
>
> Why do you think that would be the case?
In my experience here, it's hard for others to help until a patch is
nearly complete. Once there is something buildable and testable, more
input is available. You'll have to scratch your own itch first!
I hope this doesn't discourage you, I'd love to see these developments
happen and have been an outstanding proponent here for GUI/modern
features several times in the past. While you may not find a lot of
direct support, I think most features are generally accepted by the
community if they are modular, don't impact any of Vim's current
feature set, and have been developed in good style without bugs.
Ben Fritz
On Jul 26, 7:44 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
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.
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.
>
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).
>
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.
>
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.
>
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!
Tobbe Lundberg
So I'll wait and see. Hopefully someone comes along that would like to work on this together with me! I won't start on anything on my own.
I have a small kid, a house to take care of and a full time job, so my time to spend on this will be limited, 6 hours a week maybe. Plus discussing on IRC/email, doing some research etc. But since I use vim daily I can certainly see myself spending several years on supporting/updating this as needed.
John Beckett
> So the general consensus seems to be that it would be nice to
> have a more modern GUI, if it's all optional and doesn't
> limit the uses of vim in any way. You all also seem to agree
> that this is a big undertaking and that I shouldn't do it alone.
There is one more wet blanket you need to be aware of.
Suppose that after a lot of effort and testing, some changes
were proposed that involved adding a thousand lines of code,
along with fifty #ifdef, and involving several source files.
It may be the case that the complexity would rule out acceptance
of the proposed changes since adding stuff to the source makes
future maintenance and development more difficult.
My suggestion would be to start by getting a good feel for how
many source files and #ifdef features would be involved. Also,
think about compatability with existing behaviour. For example,
when multiple windows are displayed in current Vim, each window
has a customisable status line. How would that work with the
"modern GUI" style?
John
Tony Mechelynck
> 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.
Benjamin R. Haskell
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
Tobbe Lundberg
> 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
>
> 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.
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.
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
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"?
Tobbe Lundberg
On Thursday, July 28, 2011 8:08:24 AM UTC+2, Benjamin R. Haskell wrote:
>> 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.
Tobbe Lundberg
On Thursday, July 28, 2011 12:28:52 AM UTC+2, JohnBeckett wrote:
There is one more wet blanket you need to be aware of.
It may be the case that the complexity would rule out acceptance
of the proposed changes since adding stuff to the source makes
future maintenance and development more difficult.
My suggestion would be to start by getting a good feel for how
many source files and #ifdef features would be involved.
Also, think about compatability with existing behaviour. For example,
when multiple windows are displayed in current Vim, each window
has a customisable status line. How would that work with the
"modern GUI" style?
//Tobbe
Ben Fritz
On Jul 28, 3:46 am, Tobbe Lundberg <to...@tlundberg.com> wrote:
> On Thursday, July 28, 2011 12:28:52 AM UTC+2, JohnBeckett wrote:
> > There is one more wet blanket you need to be aware of.
>
> > It may be the case that the complexity would rule out acceptance
> > of the proposed changes since adding stuff to the source makes
> > future maintenance and development more difficult.
>
> While not my first choice I could maintain this as a set of patches against
> the official release of vim. But obviously I would much prefer it this
> became part of the official vim! :)
>
google code in Mercurial, and making/maintaining your changes there.
You can keep the close on google code associated with the Vim
repository, right from code.google.com/p/vim. Or, you could make a new
project on google code or bitbucket which is actually a clone but not
obviously associated.
Then collaborative development can occur easier as well.
niva
Last year, I have introduce the same idea : relooking gvim and keeping
philosophy in order to welcome new users.
This Idea gets many Opponents and since this day I am using gvim with
philosophy and only as vim user.
For instant, I have recently done my own version of gvim with new
icons, 48px toolbar height and I have spend time to make innosetup
installer that is more compliant than the existing one under seven.
You can try my installer to see if you like the look that I have done:
http://www.megaupload.com/?d=FPBAVN5V
This installer embed my gvim linked version base upon 7.3.246.
You can deploy program.
Good test!
Tobbe Lundberg
For instant, I have recently done my own version of gvim with new
icons, 48px toolbar height and I have spend time to make innosetup
installer that is more compliant than the existing one under seven.
Can you post a screen shot somewhere please? I'm very interested in how this looks!
niva
Tobbe Lundberg
On Thursday, July 28, 2011 10:19:30 PM UTC+2, niva wrote:
You can try my installer to see if you like the look that I have done:
http://www.megaupload.com/?d=FPBAVN5V
The installer asks for a password (I think, it's all in French or something, which I don't read). What is the password?
niva
Thank you
Tobbe Lundberg
It's amazing what some modern looking icons can do! This looks much fresher than the official gvim release :)
(But personally I prefer 16px icons to leave more room for text on my screen.)
Thanks for sharing this!
BTW, do you have a link to the old discussion you had? It should be in one of the online mailing list archives somewhere.
niva
>> differently than in other applications.
sufficient to be different to other applications.
I explain my aim.
What I really like with this toolbar is that it can be extendable
cause there is a static icon's part and a dynamic icon's part
In the screenshot I have upload, the static part are icon's that go to
help icon.
The others are added by amenu features in my _vimrc.
But the dynamic part of this toolbar has a static width (Screen width
minus static part width) => no more than 4 or 5 icons can be added.
So, what I have never seen on others applications is a part of a
toolbar that is sliding.
I think it would be useful and Innovative because sliding this
toolbar's part will permit us to
add infinite number of icon (under each icon I launch a vimscript
func)
Think about it (idea launch last year!)
ni va
--
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
AK
If backwards compatibility was not an issue at all, what would be
changed in vim? How many people would prefer it if at some point
there was a significant break from current codebase and vimL would
be changed to something similar to ruby or python, even if that
broke ALL currently available scripts, maybe there was a split into
separate terminal and gui versions that would share some libraries.
I think I'd be in favor of all of that even though I realize it
won't happen.
But it's interesting to discuss which things are being kept because
people use them and like them and what's being kept exclusively for
backwards compatibility.
Sorry if this was discussed to death before, I don't think I've
seen this raised and quick googling turns up nothing.
-ak
Tim Chase
> If backwards compatibility was not an issue at all, what would
> be changed in vim?
I think my biggest ones (that occur to me without profound
consideration) are actually pretty minor:
1) that {count}>{motion} and {count}<{motion} would shift by
{count} 'shiftwidth's instead of act as a multiplier for
{motion}. It happens to work as I expect/want in Visual mode, it
just behaves differently in normal mode. I'd like to be able to type
3>2j
to indent this-and-the-next-two-lines by 3 'shiftwidth's instead
of indent 6 lines by one 'sw'; or have
3>}
indent the through the end of the paragraph by 3 'sw' instead of
indenting 3} by one 'sw'.
2) that the "a"/outer quotation text-objects had a way to delete
the quotes but not the surrounding space(s). There have been a
number of times where I have Python code like
foo = [
"my cursor in here",
"some other stuff",
]
and I want to change the string to a variable, so I type
ca"
it strips the leading whitespace in addition to the quotes.
Niggling, and easily i_CTRL-T'd back into place, but it would be
nice to have a "just do the quotes and their contents, not the
spaces" tweak.
3) the definitions of 'paragraphs' are tightly tied to nroff
macros. There are times I'd like to be able to define these more
broadly (HTML tags, Python def/class statements, etc). Usually
this involves much more complex mappings.
4) a couple times, I've wished for true vi ":open" mode.
:help :open
This is less significant since I changed jobs a while back (Vim
redraw didn't work well on an old Dos-based Epson hand-held, so I
fell back to using nvi or stevie).
Most of my other annoyances are "the default for the setting that
controls $THING doesn't default *my* way" which is a pretty petty
gripe since Vim offers the functionality I want if I turn it on.
-tim
Marko Mahnič
> [...] vimL would
> broke ALL currently available scripts, maybe there was a split into
> separate terminal and gui versions that would share some libraries.
> I think I'd be in favor of all of that even though I realize it
> won't happen.
>
to Yzis. It's a rewrite of Vim in C++ and uses Lua for scripting.
It looks like the development stopped in 2010. Some code repositories
still exist:
https://bitbucket.org/fishman/yzis
http://sources.freehackers.org/hg.cgi/Yzis/summary
If you like GUI take a look at Pida. It is an IDE that integrates any
(Xwin) editor that is available on the system. It's written in Python
and works on Linux.
http://pida.co.uk/
Marko
Ben Fritz
On Jul 28, 4:23 pm, AK <andrei....@gmail.com> wrote:
> Since we're talking about this, I have a somewhat related question..
>
> If backwards compatibility was not an issue at all, what would be
> changed in vim?
strengths of Vim is the plethora of ready-made plugin solutions to a
wide variety of problems.
> How many people would prefer it if at some point
> there was a significant break from current codebase and vimL would
> be changed to something similar to ruby or python, even if that
> broke ALL currently available scripts,
its continued existence, is that most of the language is made up
of :ex commands which you can/do use in your normal interactions with
the editor. Learning VimL is mostly equivalent to learning to use Vim
itself.
For this reason, I think it would be a really bad idea to make
significant changes to VimL for the sake of making it look more like
another language.
I would certainly not be opposed to making changes to the Perl,
python, Ruby, etc. interfaces where they are lacking, for example it
would be nice to be able to pass complex variables back and forth
between Vim and the scripting language being used.
> maybe there was a split into
> separate terminal and gui versions that would share some libraries.
the sake of making changes.
Ben Fritz
> 3) the definitions of 'paragraphs' are tightly tied to nroff
> macros. There are times I'd like to be able to define these more
> broadly (HTML tags, Python def/class statements, etc). Usually
> this involves much more complex mappings.
>
definition of a sentence. I will often be editing HTML like:
<p>Mary had a little lamb. Its fleece was white as snow.</p>
das on the second sentence also deletes the closing tag and every
closing tag after it until the unconfigurable definition of a
"sentence" is reached.
On my TODO list is to figure out a way to make a closing HTML tag also
end a paragraph, if that's possible. I see that and end of paragraph
or end of section also ends a section.
tux.
> I took the liberty to post it online for direct viewing:
> http://img97.imageshack.us/img97/2127/nivavim.png
>
> It's amazing what some modern looking icons can do! This looks much fresher
> than the official gvim release :)
Reminds me of jEdit. :-)
Anyway, Vim was never about shiny toolbars. Actually, using toolbars for
a keyboard-driven editor is a rather uncommon intention after all.
Nevertheless I like the look. :-)
S.
AK
>
>
> On Jul 28, 4:23 pm, AK<andrei....@gmail.com> wrote:
>> Since we're talking about this, I have a somewhat related question..
>>
>> If backwards compatibility was not an issue at all, what would be
>> changed in vim?
>
> But, backwards compalitibility will always be an issue. One of the
> strengths of Vim is the plethora of ready-made plugin solutions to a
> wide variety of problems.
I understand, but I thought it's an interesting question to explore
anyway.
>
>> How many people would prefer it if at some point
>> there was a significant break from current codebase and vimL would
>> be changed to something similar to ruby or python, even if that
>> broke ALL currently available scripts,
>
> One of the biggest strengths of VimL, and probably the main reason for
> its continued existence, is that most of the language is made up
> of :ex commands which you can/do use in your normal interactions with
> the editor. Learning VimL is mostly equivalent to learning to use Vim
> itself.
Well, in python interface you can do something like:
from vim import command as c
def normal(cmd):
c("normal "+cmd)
so commands can be run as
c('bnext')
normal('3jyy')
etc.
I think that's about as easy as using vimL.
But in many ways languages like python and ruby are cleaner and
nicer than vimL.. for example, in python all functions, vars and
classes are in module's namespace, not global, so if you need
to use it you can do
import mymodule
mymodule.myfunc()
and not worry about name clashes.
putting vars into strings is much cleaner:
exec 'let ' . a:var . ' = ' . "'" . a:value . "'"
cmd = "let %s = '%s'" % (var, value)
What's easier to read? And that's just 2 vars..
Function args are very powerful and easy to use:
def myfunc(x, y, z=0): ..
myfunc(1, 2)
or:
args = [1,2]
kwargs = {z:3}
myfunc(*args, **kwargs)
String indexes, slices and methods are great to have:
s = 'hello'
s[2] # l
s[-2:] # lo
s[1:2] # el
s.capitalize().rstrip('o') # Hell
Triple quotes are much easier, IMHO, than vimL's varying handling of quotes:
"""Can use 'single', "double" quotes to heart's content."""
I have to run but I'm sure I could come up with a lot more...
>
> For this reason, I think it would be a really bad idea to make
> significant changes to VimL for the sake of making it look more like
> another language.
>
> I would certainly not be opposed to making changes to the Perl,
> python, Ruby, etc. interfaces where they are lacking, for example it
> would be nice to be able to pass complex variables back and forth
> between Vim and the scripting language being used.
It would be good if they were better integrated, I'm not sure how
it works internally but I think an interpreter is started every time,
for example, when you use a mapping that uses one of those languages.
I tried writing a folding function once and it was too slow compared
to vimL version. It would be great if a script could be running
alongside vim, monitor contents of current line and step in when it
matches some criteria. It would be great if a script could run in
a thread and communicate back to vim.
>
>> maybe there was a split into
>> separate terminal and gui versions that would share some libraries.
>
> What would be the point of this? I disagree with making changes for
> the sake of making changes.
I could be wrong but I think a lot of things are not done for Gvim
because they have to work in console version, too. For example a lot
of shortcuts are not possible in Gvim like ctrl-;, ctrl-", I think
because keypress processing code is shared between console and gui
Vim?
I wonder if most Vim users fall into 2 categories: those who use
gvim 95% of time and those who use console version 95% of time. If
that was the case, having less compatibility between the two
would not be a problem.
-ak
Ben Fritz
On Jul 29, 7:23 pm, AK <andrei....@gmail.com> wrote:
> On 07/29/2011 02:51 PM, Ben Fritz wrote:
>
>
> > One of the biggest strengths of VimL, and probably the main reason for
> > its continued existence, is that most of the language is made up
> > of :ex commands which you can/do use in your normal interactions with
> > the editor. Learning VimL is mostly equivalent to learning to use Vim
> > itself.
>
> Well, in python interface you can do something like:
>
> from vim import command as c
> def normal(cmd):
> c("normal "+cmd)
>
> so commands can be run as
>
> c('bnext')
> normal('3jyy')
>
> etc.
>
> I think that's about as easy as using vimL.
>
VimL but apparently won't be usable in scripts, and python. Why not
just use VimL? My point that learning how to use Vim automatically
teaches you basic Vim scripting stands regardless of whether you can
use VimL commands in python or not.
> But in many ways languages like python and ruby are cleaner and
> nicer than vimL.. for example, in python all functions, vars and
> classes are in module's namespace, not global, so if you need
> to use it you can do
>
> import mymodule
> mymodule.myfunc()
>
> and not worry about name clashes.
>
problem. Most authors prefix with the plugin name any variables,
functions, and the like which are part of an external API, or they use
<Plug>. Internal variables and functions mostly use s: to make them
private to the script.
Yes, it's a neat feature missing from vimscript, but it's hardly
crippling. People have been coding in C for decades without using
namespaces.
> putting vars into strings is much cleaner:
>
> exec 'let ' . a:var . ' = ' . "'" . a:value . "'"
>
> cmd = "let %s = '%s'" % (var, value)
>
> What's easier to read? And that's just 2 vars..
>
let {a:var} = {a:value}
:help curly-braces-names for details.
Again, this is completely missing from many languages in common use.
And actually for this purpose, i find Vim easier to read.
> Function args are very powerful and easy to use:
>
> def myfunc(x, y, z=0): ..
>
> myfunc(1, 2)
>
> or:
>
> args = [1,2]
> kwargs = {z:3}
> myfunc(*args, **kwargs)
>
like you're demonstrating 2 things:
1. In Python, you can define functions in a way that you do not need
to call them with all the arguments defined. Vim can also do this.
Admittedly, Vim does not provide a built-in way to provide defaults
for those arguments, but it is not hard to check for their absence and
default some internal variable to some value.
2. I'm really fuzzy on this one (the syntax is very cryptic IMO, and I
don't know python at all), but in python, perhaps you can pass in
arguments as part of a list instead of passing them in as defined in
the function prototype. While an interesting feature, I fail to see
the utility. It looks like a good way to obfuscate code to me.
> String indexes, slices and methods are great to have:
>
> s = 'hello'
> s[2] # l
> s[-2:] # lo
> s[1:2] # el
awkward to use.
> s.capitalize().rstrip('o') # Hell
>
over having functions which act on strings.
> Triple quotes are much easier, IMHO, than vimL's varying handling of quotes:
>
> """Can use 'single', "double" quotes to heart's content."""
>
escaping mechanisms required by almost every other language, including
VimL.
>
> It would be good if they were better integrated, I'm not sure how
> it works internally but I think an interpreter is started every time,
> for example, when you use a mapping that uses one of those languages.
> I tried writing a folding function once and it was too slow compared
> to vimL version. It would be great if a script could be running
> alongside vim, monitor contents of current line and step in when it
> matches some criteria. It would be great if a script could run in
> a thread and communicate back to vim.
>
>
of the "background command" and interactive shell plugins work, but
maybe I'm mistaken. I haven't looked into any of these. Like I said,
though, better integration with the interpreters would probably be a
plus.
I'm surprised to hear you found python slower than Vim for something.
One of the big reasons given for writing in a different scripting
language is speed improvements. Maybe there's just a big tradeoff if
you call the interpreter for small tasks many times instead of one big
task a few times.
>
> >> maybe there was a split into
> >> separate terminal and gui versions that would share some libraries.
>
> > What would be the point of this? I disagree with making changes for
> > the sake of making changes.
>
> I could be wrong but I think a lot of things are not done for Gvim
> because they have to work in console version, too. For example a lot
> of shortcuts are not possible in Gvim like ctrl-;, ctrl-", I think
> because keypress processing code is shared between console and gui
> Vim?
>
gvim cannot process codes. A lot of it has to do with the internal
encoding of those keycodes, if I understand correctly (it all sounds
very complicated to me). There have been multiple proposals (some very
recently) for updating Vim so that both console AND gvim can use most
key combinations in mappings. But, nobody has stepped up and written a
patch. So far, it's been a request only.
> I wonder if most Vim users fall into 2 categories: those who use
> gvim 95% of time and those who use console version 95% of time. If
> that was the case, having less compatibility between the two
> would not be a problem.
>
the same no matter where you run it. Putting that in jeopardy by
splitting it into two separate apps seems silly at best. People can
and do build a Vim without GUI enabled if it really matters to them,
so I don't think you'd buy much except for new places to introduce
differences in behavior between console and gvim.
Christian Brabandt
On Fr, 29 Jul 2011, Ben Fritz wrote:
> > s = 'hello'
> > s[2] � # l
> > s[-2:] # lo
> > s[1:2] # el
> Agree, these would be nice to have. There's strpart() but it can be
> awkward to use.
That works in Vim as well:
:h expr8
Agreed, indexing on bytes has its own disadvantages, so I usually don't
use it...
regards,
Christian
--
Ich bin der Wahrheit verpflichtet, wie ich sie jeden Tag erkenne, und
nicht der Best�ndigkeit.
-- Mahatma Gandhi
Tony Mechelynck
[...]
> 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.
IMHO this could still be 100% compatible. I think the font would not
necessarily have to be smaller (after all, the current 'statusline'
option uses the same 'guifont' as the rest of the window, with added
empty space or filename truncation to make everything fit. I suppose
that in this case it would be permissible to use a different font on the
status line (as in the tooltip balloons and the menus, for Athena and
Motif), but is it possible to use both font= and gui= guibg= guifg=
guisp= in a single :hi command? Or else, a new option, defaulting to
'guifont' if empty.
> 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.
Why reinvent the wheel? Option 2 above seems perfectly viable to me, if
it can be implemented.
>
> (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"?
The kind of tabs you get above the Vim screen contents, in console mode,
or in GUI mode with the e flag excluded from 'guioptions'. It is
customizable with the 'tabline' option. When empty (default), Vim uses
"a default tab pages line". To see what it looks like in gvim, use
:set go-=e stal=2
(where 'stal' or 'showtabline' has possible values 0=never, 1=only if at
least 2 tabs present, 2=always).
Historically, the text-style tabline appeared a few snapshots earlier
than the GUI-style tabline (with go+=e and 'guitablabel') during Vim 7.0
alpha development and I adopted it immediately. I still use it because
it gives me a more uniform look & feel between vim and gvim.
Best regards,
Tony.
--
The law will never make men free; it is men who have got to make the
law free.
-- Henry David Thoreau
Tobbe Lundberg
> > 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.
> IMHO this could still be 100% compatible. I think the font would not
> necessarily have to be smaller (after all, the current 'statusline'
> option uses the same 'guifont' as the rest of the window, with added
> empty space or filename truncation to make everything fit.
everything is placed at the exact same location. Using a GUI status
bar I think the border of the bar would take up too many pixels to
use the same size font as gvim does now. And because of the left
side border everything (left-aligned) would be pushed a few pixels
to the right.
> but is it possible to use both font= and gui= guibg= guifg=
> guisp= in a single :hi command?
> > 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.
> Why reinvent the wheel? Option 2 above seems perfectly viable to me, if
> it can be implemented.
information in the status bar. One field for cursor location, one for
file encoding, one for file size etc...
> > What do you mean by "text-style tabs"?
> The kind of tabs you get above the Vim screen contents, in console mode,
> or in GUI mode with the e flag excluded from 'guioptions'. It is
> customizable with the 'tabline' option. When empty (default), Vim uses
> "a default tab pages line". To see what it looks like in gvim, use
> :set go-=e stal=2
better looking (and uses less space) than something like minibufexpl
Tony Mechelynck
> On Sunday, July 31, 2011 4:10:22 AM UTC+2, Tony Mechelynck wrote:
> > :set go-=e stal=2
>
> Nice! I wish I could get a line like that for my open buffers! Much
> better looking (and uses less space) than something like minibufexpl
For buffers in windows of the current tab page, there are of course the
status lines; the non-current windows can be squashed to zero height if
desired, see http://vim.wikia.com/wiki/Window_zooming_convenience and
scroll down to the line starting "Moved from" (without the quotes).
I use a custom 'tabline' which prefixes the filename on each tab by
something like 2:3/7 meaning: "Tab page 2, window 3 of 7". The function
itself is 34 lines long (but written for legibility rather than sparseness).
Best regards,
Tony.
--
"I can remember when a good politician had to be 75 percent ability and
25 percent actor, but I can well see the day when the reverse could be
true."
-- Harry Truman