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

Re: The future of Vim on the Mac

Expand Messages
  • 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 1 of 25 , Oct 2 2:17 AM
      > 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 2 of 25 , Oct 2 8:41 AM
        > 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 3 of 25 , Oct 3 12:14 AM
          > 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 4 of 25 , Oct 3 1:31 AM
            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 5 of 25 , Oct 3 3:02 AM
              > > > 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 6 of 25 , Oct 3 4:33 AM
                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 7 of 25 , Oct 3 5:43 AM
                  > 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 8 of 25 , Oct 3 1:25 PM
                    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 9 of 25 , Oct 3 1:33 PM
                      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 10 of 25 , Oct 8 1:35 PM
                        > > > 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.