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.
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 ]
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.
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
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.
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
>> 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.
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?
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
--
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
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
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
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.
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
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
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
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