The future of Vim on the Mac
björn
Vim on the Mac. Recently Bram also stated that he does not know which
version should be integrated into the Vim source trunk so I think it
is time I made my case for why I think MacVim is the future of Vim on
the Mac. Though it is impossible for me to be objective on this
subject (being the author of MacVim) I will still make an attempt to
retain some semblance of objectivity. I sincerly hope I will not
offend anybody in the process.
The history of MacVim
=====================
Ever since I first started using a Mac (before OS X) I have been
waiting for somebody to write a good port of Vim. Last year (2006) in
September I felt that I had waited long enough and that the Carbon
port was not going anywhere, so I decided to take matters into my own
hands.
My main criterion for a new port was that it would behave like a real
Mac application that could compare with existing editors (e.g. Text
Mate) in terms of Mac integration. As such it had to be a multi
window app, and therefore I could immediately discard the option of
simply "improving" the Carbon code. Any new port had to be rewritten
from scratch. Knowing that I would not have that much time to work on
a new port (and knowing how time consuming it is to debug new code) I
had to use existing frameworks as much as possible. The only logical
option was to use Apple's Cocoa framework to as large an extent as
possible. (Note that I strongly disagree with the mentality of using
a framework simply because "it is the popular thing to do"; I
primarily chose to use Cocoa because it allowed for more rapid
development then with Carbon.)
The first couple of months I spent trying various approaches on how to
implement the multi window feature. I finally decided that there were
only two viable options:
1) Add the multi window feature to the Vim code
2) Run one Vim process for each window
The first would require more time than I had at my disposal (I also
read posts with Bram objecting to such a feature), which left me with
no other choice than "door number two".
At first I thought that communicating between multiple process might
be too slow, but consider this: each input server in OS X runs its own
process, so this is not something abhorrent in the OS X universe. I
did some tests on the round-trip time for a keystroke to go from my
app, to Vim, and back to my app again, and found that it was perfectly
acceptable. Thus satisfied, I started working on what was to become
MacVim in earnest.
The present
===========
MacVim is now in such a state that it looks and feels like a Mac
application. It supports most of the GUI specific features of Vim
such as: tabline, toolbar, and scrollbars. Furthermore it supports
features like client/server which has not been available on the Mac
before MacVim and it also comes with documentation. All in all,
MacVim works and it is available now.
More importantly, several people are using MacVim and have expressed
their happiness with it. At the moment I have two developers
contributing with patches (George Harker and Nico Weber), and several
people who are reporting bugs and suggesting new features.
However, MacVim still lacks some major features such as printing,
localized menus, and multibyte support is good but not perfect (e.g.
composing characters are not yet supported). I am actively working on
implementing these missing features and trying hard to fix bugs as
soon as they are reported.
The future
==========
I think Vim is a great editor that deserves to have a greater
following on the OS X platform. MacVim is my contribution to this
quest; it is my idea of what Vim on the Mac should be like, and I hope
that it will satisfy the wishes of other Vim users as well as attract
new users to Vim. In order for this to happen it needs more
visibility and I think an important step would be to integrate it with
the main Vim trunk (make it "official" so to speak).
Personally, I have no desire to be the face of the "Vim movement" on
the Mac, and I would gladly retire MacVim in favour of any other
superior port of Vim to the Mac. However, at the moment there simply
is no such port because all the alternatives suffer from the lack of a
multi window feature, and unless somebody makes Vim multi window they
will never have that feature without duplicating what has already been
done in MacVim.
That being said, I admire the effort Jiang has put into his vim-cocoa
port and I would very much like to know if the drawing code of
vim-cocoa is superior to that of MacVim. If that were the case I
sincerely hope that he would be willing to integrate it with MacVim.
Apart from that I do not know much of vim-cocoa, but perhaps there are
also other areas which MacVim could benefit from.
To conclude, I want Vim on the Mac to be (at least) the equal of other
editors on the Mac as well as Vim on other platforms. If this is to
happen I think we need to make a concentrated joint effort to develop
and support Vim on the Mac. Without adding a multi window feature to
Vim, I think MacVim is the only viable base for such an effort and I
will continue to work on it as long as people keep using it.
Sincerely,
Björn Winckler
Jjgod Jiang
2007/9/29, björn <bjorn.w...@gmail.com>:
> To conclude, I want Vim on the Mac to be (at least) the equal of other
> editors on the Mac as well as Vim on other platforms. If this is to
> happen I think we need to make a concentrated joint effort to develop
> and support Vim on the Mac. Without adding a multi window feature to
> Vim, I think MacVim is the only viable base for such an effort and I
> will continue to work on it as long as people keep using it.
1. At present, MacVim is more mature and have much more features
than vim-cocoa. Some features is just too "Mac-like" that I may never
implement it in vim-cocoa, for me, I just hope vim-cocoa has all the
functionalities of the Carbon version, let it be more "Vim-like".
2. MacVim and vim-cocoa is not mutually exclusive, with some small
modifications to configure.ac, we can make both MacVim and vim-cocoa
as options of --enable-gui. (the build process of MacVim is a bit more
complicated than vim-cocoa and carbon vim, but it's still possible to fit
it into the original vim build infrastructure.)
3. At present, there is still no "offical" binary release of vim on mac,
vim.org/download simply point to macvim.org for new releases.
- Jiang
Nico Weber
> port and I would very much like to know if the drawing code of
> vim-cocoa is superior to that of MacVim. If that were the case I
> sincerely hope that he would be willing to integrate it with MacVim.
> Apart from that I do not know much of vim-cocoa, but perhaps there are
> also other areas which MacVim could benefit from.
I noticed today that there is a vim-cocoa binary available at http://
code.google.com/p/vim-cocoa/downloads/list (and has been there for
nearly two weeks). I downloaded it and played around with it a bit
(Jigod: Please announce releases on this list).
I has by far not as many features as MacVim (no gui tabs, no gui
confirmation sheet if you close an open buffer, font selection dialog
is modal, no toolbar, no life resize, no clientserver -- and
obviously only one window). It has more bugs (the scrollbar is broken
when you start it up. it works if you `:e` a file, but as soon as you
do `:new`, it's broken again, ...). It uses the default vim menu
which is not as nice
But: It's _way_ faster. Startup is immediate (MacVim is not much
slower here, though, it starts pretty fast as well). And drawing is a
lot faster for certain files (example file: $VIMRUNTIME/colors/
slate.vim). Open that file in both MacVim and vim-cocoa and scroll
with your trackpad. It Just Works in vim-cocoa, but it's really
sluggish (as in < 1 frame per second) in MacVim (on a MacBook Pro 2.4
GHz! For a text editor!). I originally thought that this is slow
because of some bad regex in the syntax file for vim files, but it's
fast in vim-cocoa, so it might be related somehow else to how vim
does syntax coloring (I guess and hope that this can be improved for
MacVim). I don't know if this is due to the interprocess
communication or because vim-cocoa doesn't use a NSTextView (but a
custom view VimTextView -- shouldn't be tooooooo much effort to use
that im MacVim and try if it helps :-P).
Both seem to handle unicode well.
Looking at the source code, I think MacVim's code is nicer, but vim-
cocoa is not too bad either compared to the carbon version (it's more
or less one file -- nearly completely without comments ;-) ). (BTW: I
think both versions don't have the CodeWarrior integration carbon vim
has (which can be used to use vim from xcode from what i've heard)).
MacVim leads on nearly every front, but the speed difference is
really tremendous (for some files. Happens mainly for .vim files for
some reason).
Jigod and Bjorn, both of you have put lots of energy and time (and
code) into your versions. Understandably neither of you wants to
trash your code, but it'd be best (meaning 1. less confusing for end
users and 2. joined forces in the future) if the two of you could
chat in private and look for a way to integrate your work somehow
(all good advice contains a "somehow" in a central place :-P).
If you can't agree on something: I'm quite sure most users really
like multiple windows in vim, and doing this by changing vim will
take at least half a year (don't ask me where this estimate comes
from ;-) ). If the redraw problems of MacVim can be fixed without
this massive undertaking, this is not worth it in my eyes. Jigod, if
you want to do this, more power to you, but until you're done MacVim
should be the official binary version of vim on the mac (that doesn't
mean both versions could be in the svn repo and buildable with a
configure option, nothing wrong with that in my eyes).
In any case, both versions are better that the carbon version. And
that's great news if you think about it. So, whatever you decide:
Let's kill the carbon version. Woohoo! (and adding either a merge of
both projects or both projects with a configure option to svn would
make writing patches for them way easier. So please do this soon,
Bram. Pretty please :-) ).
- Nico
ps: "Brevity is the soul of wit" -- Shakespeare. Draw your own
conclusions :-P
Jjgod Jiang
2007/9/29, Nico Weber <nicola...@gmx.de>:
> I has by far not as many features as MacVim (no gui tabs, no gui
> confirmation sheet if you close an open buffer, font selection dialog
> is modal, no toolbar, no life resize, no clientserver -- and
> obviously only one window). It has more bugs (the scrollbar is broken
> when you start it up. it works if you `:e` a file, but as soon as you
> do `:new`, it's broken again, ...). It uses the default vim menu
> which is not as nice.
Could you please describe "no gui confirmation sheet if you close an
open buffer", "no life resize" and "the scrollbar is broken when you start
it up" for clearly? or file an issue in
http://code.google.com/p/vim-cocoa/issues/list, I'll be happy to fix them.
> Both seem to handle unicode well.
After testing with some double width (CJK) characters I found MacVim
still has some problem changing the width, it's no very easy to figure
out a solution within Cocoa Text System.
> Looking at the source code, I think MacVim's code is nicer, but vim-
> cocoa is not too bad either compared to the carbon version (it's more
> or less one file -- nearly completely without comments ;-) ). (BTW: I
> think both versions don't have the CodeWarrior integration carbon vim
> has (which can be used to use vim from xcode from what i've heard)).
I agree that MacVim's code is structured better, it's organized in an
object-oriented style, but that's _exactly_ I want avoid because I really
want everything in vim-cocoa works in vim way, including coding style.
> If you can't agree on something: I'm quite sure most users really
> like multiple windows in vim, and doing this by changing vim will
> take at least half a year (don't ask me where this estimate comes
> from ;-) ). If the redraw problems of MacVim can be fixed without
> this massive undertaking, this is not worth it in my eyes. Jigod, if
> you want to do this, more power to you, but until you're done MacVim
> should be the official binary version of vim on the mac (that doesn't
> mean both versions could be in the svn repo and buildable with a
> configure option, nothing wrong with that in my eyes).
I'm OK with that option (making MacVim as the offical binary). At
present, I don't see a quick way to tranfer vim-cocoa's text rendering
code into MacVim, because a lot of stuff in MacVim are relied on
NSTextView.
> In any case, both versions are better that the carbon version. And
> that's great news if you think about it. So, whatever you decide:
> Let's kill the carbon version. Woohoo! (and adding either a merge of
> both projects or both projects with a configure option to svn would
> make writing patches for them way easier. So please do this soon,
> Bram. Pretty please :-) ).
Agreed.
- Jiang
björn
> > confirmation sheet if you close an open buffer, font selection dialog
> > is modal, no toolbar, no life resize, no clientserver -- and
> > obviously only one window). It has more bugs (the scrollbar is broken
> > when you start it up. it works if you `:e` a file, but as soon as you
> > do `:new`, it's broken again, ...). It uses the default vim menu
> > which is not as nice.
>
> Could you please describe "no gui confirmation sheet if you close an
> open buffer", "no life resize" and "the scrollbar is broken when you start
> it up" for clearly? or file an issue in
> http://code.google.com/p/vim-cocoa/issues/list, I'll be happy to fix them.
Please, lets try to stay on topic. So Nico if you do reply to that,
do it in a new thread.
> > If you can't agree on something: I'm quite sure most users really
> > like multiple windows in vim, and doing this by changing vim will
> > take at least half a year (don't ask me where this estimate comes
> > from ;-) ). If the redraw problems of MacVim can be fixed without
> > this massive undertaking, this is not worth it in my eyes. Jigod, if
> > you want to do this, more power to you, but until you're done MacVim
> > should be the official binary version of vim on the mac (that doesn't
> > mean both versions could be in the svn repo and buildable with a
> > configure option, nothing wrong with that in my eyes).
>
> I'm OK with that option (making MacVim as the offical binary). At
> present, I don't see a quick way to tranfer vim-cocoa's text rendering
> code into MacVim, because a lot of stuff in MacVim are relied on
> NSTextView.
This is good news to me, but it would be great news if you'd consider
contributing to MacVim. The best way of doing that would be to
implement MMTextView based on your rendering code. (I really do not
use NSTextView much, it is more like I do my best to work around
it...which kind of indicates that it should not be used at all.) If
you feel that it is too much of an undertaking (something I
respect...I know how much time goes into this) then I will do it
myself (unless you object). Is there any chance I could convince you
to help out?
I just tested vim-cocoa to look for that enormous speed difference
Nico mentioned. If you disable syntax highlighting then MacVim
renders at about the same speed that vim-cocoa does with syntax
highlighting enabled! With syntax highlighting MacVim really does
suffer, so I think MacVim would benefit a great deal from your source
code Jiang. It is very impressive to see that your implementation is
so fast.
> > In any case, both versions are better that the carbon version. And
> > that's great news if you think about it. So, whatever you decide:
> > Let's kill the carbon version. Woohoo! (and adding either a merge of
> > both projects or both projects with a configure option to svn would
> > make writing patches for them way easier. So please do this soon,
> > Bram. Pretty please :-) ).
>
> Agreed.
Of course, I have no objections to having both versions in the Vim svn
(and there are no conflicts between the two since MacVim uses
FEAT_GUI_MACVIM and gui-cocoa uses FEAT_GUI_COCOA).
I would be glad if MacVim could be added to the Vim svn soon so that
it is easier to make patches to the MacVim related code in Vim (like
Nico pointed out in another thread).
/Björn
Jjgod Jiang
2007/9/30, björn <bjorn.w...@gmail.com>:
> This is good news to me, but it would be great news if you'd consider
> contributing to MacVim. The best way of doing that would be to
> implement MMTextView based on your rendering code. (I really do not
> use NSTextView much, it is more like I do my best to work around
> it...which kind of indicates that it should not be used at all.) If
> you feel that it is too much of an undertaking (something I
> respect...I know how much time goes into this) then I will do it
> myself (unless you object). Is there any chance I could convince you
> to help out?
I'm glad that I can help. But I've upgrade my whole system to a
recent seed of Leopard (9a559), got the same problem described
in http://code.google.com/p/macvim/issues/detail?id=18, so I will
try to fix the Leopard issue first, then start to find a new way to
integrate my rendering code into MacVim (or find a new way to
combine the goodness of both).
- Jiang
björn
That is great Jiang, MacVim will most certainly benefit from your
help! Let me know if I can help you out by filling you in on the
details of the code, or in any other way. Actually, if you were to
write a new MMTextView class that implemented the drawing methods much
in the same style MMTextStorage does now, then I could write the glue
code (this I expect will be the most time consuming for you) to tie in
with your text view class.
/Björn
Timothy Reaves
On Sep 29, 2007, at 8:19 AM, björn wrote:
>
> Many people have been wondering why there are three different ports of
> Vim on the Mac. Recently Bram also stated that he does not know which
> version should be integrated into the Vim source trunk so I think it
> is time I made my case for why I think MacVim is the future of Vim on
> the Mac. Though it is impossible for me to be objective on this
> subject (being the author of MacVim) I will still make an attempt to
> retain some semblance of objectivity. I sincerly hope I will not
> offend anybody in the process.
Ya, I'm not so sure the future of Vim on the Mac should be something
that is going to be horribly broken in a month when 10.5 is officially
released. If you were truly interested in making MacVim the future,
you'd be 'future-proofing' it. Yes?
Danny O'Brien
pooling their talents on this project. Thanks, Jiang, for all your
contributions!
d.
On Sep 29, 11:42 am, "Jjgod Jiang" <gzjj...@gmail.com> wrote:
> Hi,
>
> 2007/9/30, björn <bjorn.winck...@gmail.com>:
>
> > This is good news to me, but it would be great news if you'd consider
> > contributing to MacVim. The best way of doing that would be to
> > implement MMTextView based on your rendering code. (I really do not
> > use NSTextView much, it is more like I do my best to work around
> > it...which kind of indicates that it should not be used at all.) If
> > you feel that it is too much of an undertaking (something I
> > respect...I know how much time goes into this) then I will do it
> > myself (unless you object). Is there any chance I could convince you
> > to help out?
>
> I'm glad that I can help. But I've upgrade my whole system to a
> recent seed of Leopard (9a559), got the same problem described
> inhttp://code.google.com/p/macvim/issues/detail?id=18, so I will
Jeremy Conlin
>
> Can I just say how great it is to see such brilliant vim programmers
> pooling their talents on this project. Thanks, Jiang, for all your
> contributions!
>
improvements to Vim on the Mac. My friend (a big TextMate users)
recently commented on how MacVim looks so good now with the new MacVim
colorscheme.
My only regret is that I am unable to contribute to this project.
Keep up the great work.
Jeremy
vivacarlie
Nico mentioned. If you disable syntax highlighting then MacVim
renders at about the same speed that vim-cocoa does with syntax
highlighting enabled! With syntax highlighting MacVim really does
suffer, so I think MacVim would benefit a great deal from your source
code Jiang. It is very impressive to see that your implementation is
so fast.
have you guys looked at http://www.zathras.de/angelweb/sourcecode.htm#UKSyntaxColoredTextDocument
björn
> that is going to be horribly broken in a month when 10.5 is officially
> released. If you were truly interested in making MacVim the future,
> you'd be 'future-proofing' it. Yes?
I can't say I quite understand what that comment was supposed to mean;
Leopard is only available to ADC premiere and select members (which
costs $$$). Maybe this isn't obvious, but MacVim is a hobby project
which means I can only afford to put time, not money, into this
project. If that makes me "not truly interested", then so be it.
The good news is Jiang just said in a previous post on this thread
that he is looking into the Leopard issue!
/Björn
Thomas
join this discussion... Yet there's one thing I want to add: I agree
that it's a noble goal to make the Mac version of vim as Mac-like as
possible. However, there are also users who turn to a tool like vim
precisely because it is available on multiple platforms. They expect
it to work the same on the platforms they use. I work on linux and on
OS X, and I find it a relief that I can simply take my .vimrc from one
platform to the other (with minor adaptations, of course) and have the
same shortcuts, key bindings, the same behavior. So I would very much
plead for this: make MacVim or vimcocoa or whatever version as Mac-
like as you want, but please make it easy to switch back to "normal"
vim behavior, e.g., allow us an easy way to switch off the Command-C, -
V, -X shortcuts.
Just my two cents
Thomas
Ben Schmidt
> that is going to be horribly broken in a month when 10.5 is officially
> released. If you were truly interested in making MacVim the future,
> you'd be 'future-proofing' it. Yes?
This isn't actually possible, Timothy. No humble application developer can guess
what Apple (or any other operating system developer, including those of free OSes)
may change or break in a future system. All that can be done is to follow the
rules and interfaces that are available without relying on undocumented
functionality, and trust the OS developers not to change the documented
functionality. On the whole this works well, and particularly when using an
object-oriented interface such as Cocoa, it can even be quite hard to do the wrong
thing--you're almost forced to do it right! That said, when new versions of
operating systems, or other suftware upone which Vim depends (or any other
software project) are released, from time to time things break and need patching.
It's normal, unavoidable, and no big deal.
Judging from the comments I've heard on the mailing lists, the MacVim programmers
(chiefly Bjorn) are very competent, and I would be surprised if there were any
large-scale errors that would make the program any less 'future-proof' than normal.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Bram Moolenaar
Vivacarlie wrote:
> I just tested vim-cocoa to look for that enormous speed difference
> Nico mentioned. If you disable syntax highlighting then MacVim
> renders at about the same speed that vim-cocoa does with syntax
> highlighting enabled! With syntax highlighting MacVim really does
> suffer, so I think MacVim would benefit a great deal from your source
> code Jiang. It is very impressive to see that your implementation is
> so fast.
This confirms the observation made earlier that the text widget that
MacVim uses redraws inefficiently.
I know it's more work, but perhaps it's still worth using the text
drawing from vim-cocoa and integrate it with MacVim? Or the other way
around, perhaps a better way to say it is to merge the two versions.
--
People who want to share their religious views with you
almost never want you to share yours with them.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
björn
That certainly sounds like a reasonable (read: good) idea to me. One
(simple) way would be to set a variable in .vimrc and not load the
MacVim specific stuff if it is set. Would that be good enough?
By they way...to all other people on this list who feel hesitant
towards expressing your opinions or ideas regarding MacVim because you
are "only a user" or some similar reason: everybody's comments are
welcome to me, as long as they are constructive.
/Björn
Thomas
> That certainly sounds like a reasonable (read: good) idea to me. One
> (simple) way would be to set a variable in .vimrc and not load the
> MacVim specific stuff if it is set. Would that be good enough?
>
Yes, this sounds like an excellent solution. It would cater to those
who are familiar with OS X and want to have a look at Vim, and it
would allow more experienced users of Vim to keep all the movements to
which they have become accustomed. So something like :set maclike
(which should probably be set by default) and which can easily be
turned off.
Thomas
Nico Weber
> who are familiar with OS X and want to have a look at Vim, and it
> would allow more experienced users of Vim to keep all the movements to
> which they have become accustomed.
MacVim doesn't override any default mappings, it only adds mappings
which are not used in default vim (because "normal" keyboards don't
have a Cmd key). If you don't map Cmd key equivalents to something
else, all your mappings should work anyways.
Nico
Tim Allen
...and if you *do* map Cmd-key equivalents, they will[1] override
MacVim's defaults anyway.
[1] Or "should" - I haven't tried it myself, but it seems the Right
Way for this to work.
björn
Nico and Tim are right in saying that Cmd does not exist on any other
platform, and you can override such mappings anyway (with
menukeyequiv, NOT with map). However, it is quite simple to add a
check in the beginning of $VIM/gvimrc to skip sourcing it in case some
variable is set. Now that I thought some more about it I realize this
would never be a very good idea. Why? Because this will give you the
default menus, which in particular means there is no "File -> New
Window" menu entry. Without this, you can still open a new window if
one is already open (:action newWindow:), but if you close all your
windows then there is no way to open a window...all you can do is quit
and restart.
Thus, there is pretty much no option but to load $VIM/gvimrc to change
the default menus. Once this is done, why not add the key equivalents
as well?
Now, it may seem like I am contradicting myself, but what I first and
foremost had in mind when I suggested adding a variable to stop
certain things from loading in $VIM/gvimrc, I didn't have the menu
related stuff in mind. What I did think was that if there are
non-essential things in $VIM/gvimrc then it should be possible to
disable them (e.g. like the failed shift-movement experiment). I
still think this is a good idea.
Now, Thomas, do you still want to be able to not load the key
equivalents (<D-c> etc.), or do you agree that they may as well (or
should) be loaded?
/Björn
Niklas Lindström
> > MacVim doesn't override any default mappings, it only adds mappings
> > which are not used in default vim (because "normal" keyboards don't
> > have a Cmd key). If you don't map Cmd key equivalents to something
> > else, all your mappings should work anyways.
>
> ...and if you *do* map Cmd-key equivalents, they will[1] override
> MacVim's defaults anyway.
>
> [1] Or "should" - I haven't tried it myself, but it seems the Right
> Way for this to work.
It seems that $VIM/gvimrc does override my mappings. I've added some
stuff in a ~/.vim/plugin/ file to map e.g. Alt-+movements (to switch
vim windows quickly). But these are overridden by the mappings in
MacVim:s gvimrc (until I e.g. manually source my stuff).
Is this because of the order of source execution? Shouldn't personal
plugins be sourced after the system gvimrc?
Best regards,
Niklas
björn
> stuff in a ~/.vim/plugin/ file to map e.g. Alt-+movements (to switch
> vim windows quickly). But these are overridden by the mappings in
> MacVim:s gvimrc (until I e.g. manually source my stuff).
Sorry about that...I forgot that I do some mappings in $VIM/gvimrc.
Namely <D-Arrow key> and <M-Arrow key> (everything else is done via
:menukeyequiv). The <M-Arrow key> mappings should be possible to
disable at the very least.
> Is this because of the order of source execution? Shouldn't personal
> plugins be sourced after the system gvimrc?
I don't know...can anybody else answer this question?
/Björn
Thomas
On Oct 3, 12:02 pm, "björn" <bjorn.winck...@gmail.com> wrote:
>
> Now, Thomas, do you still want to be able to not load the key
> equivalents (<D-c> etc.), or do you agree that they may as well (or
> should) be loaded?
>
As I said, the default behavior should be that all these mappings and
menus are loaded - otherwise, users new to Vim would be endlessly
confused. But I still think that it would be a good thing to have the
possiblity to "unload" these features. And then, yes, I'd prefer to
unload all of them to have a vanilla Vim on OS X (which, in addition,
looks just much much better than any Vim on linux I have ever used).
But I must admit that I haven't experimented enough to see whether
this is really necessary or useful; Nico's point is of course valid.
Thomas
Niklas Lindström
>
> > It seems that $VIM/gvimrc does override my mappings. I've added some
> > stuff in a ~/.vim/plugin/ file to map e.g. Alt-+movements (to switch
> > vim windows quickly). But these are overridden by the mappings in
> > MacVim:s gvimrc (until I e.g. manually source my stuff).
>
> Sorry about that...I forgot that I do some mappings in $VIM/gvimrc.
> Namely <D-Arrow key> and <M-Arrow key> (everything else is done via
> :menukeyequiv). The <M-Arrow key> mappings should be possible to
> disable at the very least.
No problem; compared to the usefulness of MacVim that can't really
count. ;) Still, it may be useful to have some part of the system
gvimrc as optional, as you're already discussing.
> > Is this because of the order of source execution? Shouldn't personal
> > plugins be sourced after the system gvimrc?
>
> I don't know...can anybody else answer this question?
Hm, I think my assumption was wrong; skimming through the vim docs
seem to indicate that the gvimrc is sourced after normal
initialization..
Best regards,
Niklas
björn
> > > stuff in a ~/.vim/plugin/ file to map e.g. Alt-+movements (to switch
> > > vim windows quickly). But these are overridden by the mappings in
> > > MacVim:s gvimrc (until I e.g. manually source my stuff).
> >
> > Sorry about that...I forgot that I do some mappings in $VIM/gvimrc.
> > Namely <D-Arrow key> and <M-Arrow key> (everything else is done via
> > :menukeyequiv). The <M-Arrow key> mappings should be possible to
> > disable at the very least.
>
> No problem; compared to the usefulness of MacVim that can't really
> count. ;) Still, it may be useful to have some part of the system
> gvimrc as optional, as you're already discussing.
I added a check for the variable "macvim_skip_cmd_opt_movement" in
$VIM/gvimrc (r303). Set this var and no key mappings will be done
(only menu key equivalents). In the future I will try to make all of
this a bit simpler to control, but for now this will have to do.
/Björn