Loading ...
Sorry, an error occurred while loading the content.

The future of Vim on the Mac

Expand Messages
  • björn
    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
    Message 1 of 25 , Sep 29, 2007
    • 0 Attachment
      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.


      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

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Jjgod Jiang
      Hi, ... 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
      Message 2 of 25 , Sep 29, 2007
      • 0 Attachment
        Hi,

        2007/9/29, björn <bjorn.winckler@...>:
        > 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

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Nico Weber
        ... 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).
        Message 3 of 25 , Sep 29, 2007
        • 0 Attachment
          > 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.

          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

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Jjgod Jiang
          Hi, ... 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
          Message 4 of 25 , Sep 29, 2007
          • 0 Attachment
            Hi,

            2007/9/29, Nico Weber <nicolasweber@...>:
            > 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

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... Please, lets try to stay on topic. So Nico if you do reply to that, do it in a new thread. ... This is good news to me, but it would be great news if
            Message 5 of 25 , Sep 29, 2007
            • 0 Attachment
              > > 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.

              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

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Jjgod Jiang
              Hi,2007/9/30, björn : This is good news to me, but it would be great news if you d consider contributing to MacVim. The best
              Message 6 of 25 , Sep 29, 2007
              • 0 Attachment
                Hi,

                2007/9/30, björn <bjorn.winckler@...>:
                > 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

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • 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
                Message 7 of 25 , Sep 29, 2007
                • 0 Attachment
                  > > 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).

                  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

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Timothy Reaves
                  ... 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
                  Message 8 of 25 , Sep 29, 2007
                  • 0 Attachment
                    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?
                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Danny O'Brien
                    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! d. ...
                    Message 9 of 25 , Sep 29, 2007
                    • 0 Attachment
                      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!

                      d.


                      On Sep 29, 11:42 am, "Jjgod Jiang" <gzjj...@...> wrote:
                      > Hi,
                      >
                      > 2007/9/30, björn <bjorn.winck...@...>:
                      >
                      > > 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
                      > 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


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Jeremy Conlin
                      ... I too want to add my thanks to all you who are making *great* improvements to Vim on the Mac. My friend (a big TextMate users) recently commented on how
                      Message 10 of 25 , Sep 29, 2007
                      • 0 Attachment
                        On 9/29/07, Danny O'Brien <dannyobrien@...> wrote:
                        >
                        > 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!
                        >
                        I too want to add my thanks to all you who are making *great*
                        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

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • vivacarlie
                        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
                        Message 11 of 25 , Sep 29, 2007
                        • 0 Attachment
                          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.

                          have you guys looked at http://www.zathras.de/angelweb/sourcecode.htm#UKSyntaxColoredTextDocument


                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • björn
                          ... 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 $$$).
                          Message 12 of 25 , Sep 30, 2007
                          • 0 Attachment
                            > 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?

                            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

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Thomas
                            I m just a lowly user, not a developer, so I m somwhat hesitant to join this discussion... Yet there s one thing I want to add: I agree that it s a noble goal
                            Message 13 of 25 , Sep 30, 2007
                            • 0 Attachment
                              I'm just a lowly user, not a developer, so I'm somwhat hesitant to
                              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


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Ben Schmidt
                              ... This isn t actually possible, Timothy. No humble application developer can guess what Apple (or any other operating system developer, including those of
                              Message 14 of 25 , Sep 30, 2007
                              • 0 Attachment
                                > 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?

                                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


                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Bram Moolenaar
                                ... 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
                                Message 15 of 25 , Sep 30, 2007
                                • 0 Attachment
                                  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 -- Bram@... -- 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 ///

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • 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
                                  Message 16 of 25 , Oct 2, 2007
                                  • 0 Attachment
                                    > I'm just a lowly user, not a developer, so I'm somwhat hesitant to
                                    > 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.

                                    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

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • Thomas
                                    ... 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
                                    Message 17 of 25 , Oct 2, 2007
                                    • 0 Attachment
                                      > 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


                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_mac" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    • Nico Weber
                                      ... 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
                                      Message 18 of 25 , Oct 3, 2007
                                      • 0 Attachment
                                        > 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.

                                        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


                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_mac" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • 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
                                        Message 19 of 25 , Oct 3, 2007
                                        • 0 Attachment
                                          On Oct 3, 5:14 pm, Nico Weber <nicolaswe...@...> wrote:
                                          > > 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.
                                          >
                                          > 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.


                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_mac" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • 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
                                          Message 20 of 25 , Oct 3, 2007
                                          • 0 Attachment
                                            > > > 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.
                                            > >
                                            > > 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.

                                            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

                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_mac" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • Niklas Lindström
                                            Hi! ... 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
                                            Message 21 of 25 , Oct 3, 2007
                                            • 0 Attachment
                                              Hi!

                                              > > 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

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_mac" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • björn
                                              ... Sorry about that...I forgot that I do some mappings in $VIM/gvimrc. Namely and (everything else is done via ... disable at the
                                              Message 22 of 25 , Oct 3, 2007
                                              • 0 Attachment
                                                > 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.


                                                > 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

                                                --~--~---------~--~----~------------~-------~--~----~
                                                You received this message from the "vim_mac" maillist.
                                                For more information, visit http://www.vim.org/maillist.php
                                                -~----------~----~----~----~------~----~------~--~---
                                              • Thomas
                                                ... 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
                                                Message 23 of 25 , Oct 3, 2007
                                                • 0 Attachment
                                                  On Oct 3, 12:02 pm, "björn" <bjorn.winck...@...> 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


                                                  --~--~---------~--~----~------------~-------~--~----~
                                                  You received this message from the "vim_mac" maillist.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                  -~----------~----~----~----~------~----~------~--~---
                                                • Niklas Lindström
                                                  ... 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
                                                  Message 24 of 25 , Oct 3, 2007
                                                  • 0 Attachment
                                                    On 10/3/07, björn <bjorn.winckler@...> wrote:
                                                    >
                                                    > > 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

                                                    --~--~---------~--~----~------------~-------~--~----~
                                                    You received this message from the "vim_mac" maillist.
                                                    For more information, visit http://www.vim.org/maillist.php
                                                    -~----------~----~----~----~------~----~------~--~---
                                                  • björn
                                                    ... 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
                                                    Message 25 of 25 , Oct 8, 2007
                                                    • 0 Attachment
                                                      > > > 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.

                                                      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

                                                      --~--~---------~--~----~------------~-------~--~----~
                                                      You received this message from the "vim_mac" maillist.
                                                      For more information, visit http://www.vim.org/maillist.php
                                                      -~----------~----~----~----~------~----~------~--~---
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.