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

Re: mvim on file with path

Expand Messages
  • Nico Weber
    ... I haven t tested this, but I guess this is what happens: 1.) Vim starts up, parses vimrc (and sets autochdir) 2.) Vim changes the current directory because
    Message 1 of 21 , Feb 4, 2009
    • 0 Attachment
      > Hmmm...it only happens if MacVim forks; i.e. if you start with "mvim
      > -f path/filename" then everything works fine.
      >
      > Does anybody have any ideas why forking would cause this (Nico,
      > Ben, ...?).

      I haven't tested this, but I guess this is what happens:

      1.) Vim starts up, parses vimrc (and sets autochdir)
      2.) Vim changes the current directory because of autochdir
      3.) Vim forks, which basically kills vim and restarts it as a child
      process
      4.) The child process inherits the (changed) current directory
      5.) During child startup, vim tries to open the relative path
      6.) Since the current directory has changed, the relative path is not
      resolved correctly

      The best fix I can think of is to store the original directory during
      vim startup chdir() back to that in the child process before calling
      exec(). Any better suggestions?

      Nico

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • björn
      ... Yes, that must be what is happening. ... This sounds a bit too hacked together, but the only other solution I can think of is to fork earlier. At the
      Message 2 of 21 , Feb 7, 2009
      • 0 Attachment
        2009/2/5 Nico Weber:
        >
        >> Hmmm...it only happens if MacVim forks; i.e. if you start with "mvim
        >> -f path/filename" then everything works fine.
        >>
        >> Does anybody have any ideas why forking would cause this (Nico,
        >> Ben, ...?).
        >
        > I haven't tested this, but I guess this is what happens:
        >
        > 1.) Vim starts up, parses vimrc (and sets autochdir)
        > 2.) Vim changes the current directory because of autochdir
        > 3.) Vim forks, which basically kills vim and restarts it as a child
        > process
        > 4.) The child process inherits the (changed) current directory
        > 5.) During child startup, vim tries to open the relative path
        > 6.) Since the current directory has changed, the relative path is not
        > resolved correctly

        Yes, that must be what is happening.

        > The best fix I can think of is to store the original directory during
        > vim startup chdir() back to that in the child process before calling
        > exec(). Any better suggestions?

        This sounds a bit too hacked together, but the only other solution I
        can think of is to fork earlier.

        At the moment (as far as I can understand) we only fork after reading
        the rc-files because a user may add "f" to 'guioptions'. Now, my
        question is: does anybody really _need_ this functionality? If we
        crippled this option we could fork right after parsing the command
        line arguments and it would fix the above problems and potentially
        others (that we do not yet know about) as well. Another side-effect
        of this is that we don't have to perform initializations twice which
        would cut down on startup times.

        I would be much more comfortable with this solution. Comments?

        Björn

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • alexanderkahn
        ... I can t speak for anyone but myself, but I could do without the -f option (or guioptions=f). In the situation where I *would* use this feature, when
        Message 3 of 21 , Feb 9, 2009
        • 0 Attachment
          On Feb 7, 7:37 am, björn <bjorn.winck...@...> wrote:
          > At the moment (as far as I can understand) we only fork after reading
          > the rc-files because a user may add "f" to 'guioptions'.  Now, my
          > question is: does anybody really _need_ this functionality?  If we
          > crippled this option we could fork right after parsing the command
          > line arguments and it would fix the above problems and potentially
          > others (that we do not yet know about) as well.  Another side-effect
          > of this is that we don't have to perform initializations twice which
          > would cut down on startup times.
          >
          > I would be much more comfortable with this solution.  Comments?

          I can't speak for anyone but myself, but I could do without the -f
          option (or guioptions=f). In the situation where I *would* use this
          feature, when writing a commit message for git or svn, I simply use
          vim in the command line, rather than MacVim. But I imagine some people
          may use MacVim in this situation, or for writing email messages, maybe
          they will weigh in if this is the case.

          Alex
          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Holger Rapp
          Hi, ... I for one use this option on a daily basis, in fact my EDITOR variable is set to mvim -f . Greetings, Holger
          Message 4 of 21 , Feb 9, 2009
          • 0 Attachment
            Hi,

            Am 09.02.2009 um 17:03 schrieb alexanderkahn:

            >
            > On Feb 7, 7:37 am, björn <bjorn.winck...@...> wrote:
            >> At the moment (as far as I can understand) we only fork after reading
            >> the rc-files because a user may add "f" to 'guioptions'. Now, my
            >> question is: does anybody really _need_ this functionality? If we
            >> crippled this option we could fork right after parsing the command
            >> line arguments and it would fix the above problems and potentially
            >> others (that we do not yet know about) as well. Another side-effect
            >> of this is that we don't have to perform initializations twice which
            >> would cut down on startup times.
            >>
            >> I would be much more comfortable with this solution. Comments?
            >
            > I can't speak for anyone but myself, but I could do without the -f
            > option (or guioptions=f). In the situation where I *would* use this
            > feature, when writing a commit message for git or svn, I simply use
            > vim in the command line, rather than MacVim. But I imagine some people
            > may use MacVim in this situation, or for writing email messages, maybe
            > they will weigh in if this is the case.
            I for one use this option on a daily basis, in fact my EDITOR variable
            is set to
            'mvim -f'.

            Greetings,
            Holger


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... Ok, hold on for a moment here. I suggested deprecating f in guioptions ONLY. It will still be possible to pass the -f flag on the command line!!!
            Message 5 of 21 , Feb 9, 2009
            • 0 Attachment
              2009/2/9 Holger Rapp:
              >
              > Am 09.02.2009 um 17:03 schrieb alexanderkahn:
              >
              >> On Feb 7, 7:37 am, björn wrote:
              >>> At the moment (as far as I can understand) we only fork after reading
              >>> the rc-files because a user may add "f" to 'guioptions'. Now, my
              >>> question is: does anybody really _need_ this functionality? If we
              >>> crippled this option we could fork right after parsing the command
              >>> line arguments and it would fix the above problems and potentially
              >>> others (that we do not yet know about) as well. Another side-effect
              >>> of this is that we don't have to perform initializations twice which
              >>> would cut down on startup times.
              >>>
              >>> I would be much more comfortable with this solution. Comments?
              >>
              >> I can't speak for anyone but myself, but I could do without the -f
              >> option (or guioptions=f). In the situation where I *would* use this
              >> feature, when writing a commit message for git or svn, I simply use
              >> vim in the command line, rather than MacVim. But I imagine some people
              >> may use MacVim in this situation, or for writing email messages, maybe
              >> they will weigh in if this is the case.
              > I for one use this option on a daily basis, in fact my EDITOR variable
              > is set to
              > 'mvim -f'.

              Ok, hold on for a moment here. I suggested deprecating "f" in
              'guioptions' ONLY. It will still be possible to pass the "-f" flag on
              the command line!!! (I would assume _lots_ of people use this flag.)

              Björn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Holger Rapp
              ... Alright, misunderstood you here. I wasn t aware of this feature and I agree that it seems pretty useless. I would guess that forking is done for mvim even
              Message 6 of 21 , Feb 9, 2009
              • 0 Attachment
                > Ok, hold on for a moment here. I suggested deprecating "f" in
                > 'guioptions' ONLY. It will still be possible to pass the "-f" flag on
                > the command line!!! (I would assume _lots_ of people use this flag.)
                Alright, misunderstood you here. I wasn't aware of this feature and I
                agree
                that it seems pretty useless. I would guess that forking is done for
                mvim even
                before the vim process is spawned... However, I also could do without
                this in
                guioptions.

                Greetings,
                Holger


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Nico Weber
                ... Here s what I wrote a year ago on this subject: http://groups.google.com/group/vim_mac/browse_thread/thread/9fcc068f20e82942/b009aced253e89ad In short,
                Message 7 of 21 , Feb 9, 2009
                • 0 Attachment
                  > > The best fix I can think of is to store the original directory during
                  > > vim startup chdir() back to that in the child process before calling
                  > > exec(). Any better suggestions?
                  >
                  > This sounds a bit too hacked together, but the only other solution I
                  > can think of is to fork earlier.
                  >
                  > At the moment (as far as I can understand) we only fork after reading
                  > the rc-files because a user may add "f" to 'guioptions'.  Now, my
                  > question is: does anybody really _need_ this functionality?  If we
                  > crippled this option we could fork right after parsing the command
                  > line arguments and it would fix the above problems and potentially
                  > others (that we do not yet know about) as well.  Another side-effect
                  > of this is that we don't have to perform initializations twice which
                  > would cut down on startup times.
                  >
                  > I would be much more comfortable with this solution.  Comments?

                  Here's what I wrote a year ago on this subject:
                  http://groups.google.com/group/vim_mac/browse_thread/thread/9fcc068f20e82942/b009aced253e89ad

                  In short, forking earlier has its problems too. You probably don't
                  want to do command line flag handling yourself (so that things like "-
                  gf" vs "-fg" and "-f" after "--remote" etc are handled correctly). But
                  vim might already modify the environment when parsing command line
                  flags, so parts of the environment might need to be restored even if
                  forking earlier.

                  To me, this sound like trading one can of worms for another.

                  Nico
                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... Hmmm...let me be a bit more precise: I suggest forking right after command_line_scan(). This way we don t need to parse any command line flags ourselves.
                  Message 8 of 21 , Feb 9, 2009
                  • 0 Attachment
                    2009/2/9 Nico Weber:
                    >
                    >> > The best fix I can think of is to store the original directory during
                    >> > vim startup chdir() back to that in the child process before calling
                    >> > exec(). Any better suggestions?
                    >>
                    >> This sounds a bit too hacked together, but the only other solution I
                    >> can think of is to fork earlier.
                    >>
                    >> At the moment (as far as I can understand) we only fork after reading
                    >> the rc-files because a user may add "f" to 'guioptions'. Now, my
                    >> question is: does anybody really _need_ this functionality? If we
                    >> crippled this option we could fork right after parsing the command
                    >> line arguments and it would fix the above problems and potentially
                    >> others (that we do not yet know about) as well. Another side-effect
                    >> of this is that we don't have to perform initializations twice which
                    >> would cut down on startup times.
                    >>
                    >> I would be much more comfortable with this solution. Comments?
                    >
                    > Here's what I wrote a year ago on this subject:
                    > http://groups.google.com/group/vim_mac/browse_thread/thread/9fcc068f20e82942/b009aced253e89ad
                    >
                    > In short, forking earlier has its problems too. You probably don't
                    > want to do command line flag handling yourself (so that things like "-
                    > gf" vs "-fg" and "-f" after "--remote" etc are handled correctly). But
                    > vim might already modify the environment when parsing command line
                    > flags, so parts of the environment might need to be restored even if
                    > forking earlier.
                    >
                    > To me, this sound like trading one can of worms for another.

                    Hmmm...let me be a bit more precise: I suggest forking right after
                    command_line_scan(). This way we don't need to parse any command line
                    flags ourselves. Isn't this easier than fixing every problem such as
                    the one with 'autochdir' each time they pop up?

                    What parts of the environment may have changed before that? I had a
                    quick look but couldn't see any problems.

                    Sure this may be "trading one can of worms for another", but I would
                    like to understand the two alternatives better than I do now so that I
                    can make up my own mind as to which is the lesser of the two evils.
                    Also, it seems we now have new problems (i.e. 'autochdir') that we
                    were unaware of when you wrote that other post regarding forking.

                    Thanks,
                    Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Nico Weber
                    ... I agree, this looks like a good place to do this. For some reason, I had assumed that vim executes the commandline flags as it parses them (e.g. -c cd
                    Message 9 of 21 , Feb 9, 2009
                    • 0 Attachment
                      > Hmmm...let me be a bit more precise: I suggest forking right after
                      > command_line_scan(). This way we don't need to parse any command line
                      > flags ourselves.

                      I agree, this looks like a good place to do this. For some reason, I
                      had assumed that vim executes the commandline flags as it parses them
                      (e.g. -c 'cd otherdir'), but that's not true.

                      Nico

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • björn
                      ... Nico, I prepared a patch but I d appreciate it if you d look over it before I merge. In particular, I got rid of prepare_getout() since Vim hasn t even
                      Message 10 of 21 , Feb 10, 2009
                      • 0 Attachment
                        2009/2/10 Nico Weber:
                        >
                        >> Hmmm...let me be a bit more precise: I suggest forking right after
                        >> command_line_scan(). This way we don't need to parse any command line
                        >> flags ourselves.
                        >
                        > I agree, this looks like a good place to do this. For some reason, I
                        > had assumed that vim executes the commandline flags as it parses them
                        > (e.g. -c 'cd otherdir'), but that's not true.

                        Nico, I prepared a patch but I'd appreciate it if you'd look over it
                        before I merge. In particular, I got rid of prepare_getout() since
                        Vim hasn't even initialized by the time we fork now. Still, there is
                        some allocation of structures going on before we fork...do you think
                        any of this needs to be "undone" before forking? Somehow it seems
                        "safer" to just lets things be, but I'm not at all sure about this.
                        (Patches 1 and 2 are the interesting ones.)

                        Anybody else wishing to evaluate these patches are of course also
                        welcome to chime in. I haven't tested them much myself yet so there
                        may very well be some glaring bugs in there!

                        As for startup times: with these patches startup is another 200ms or
                        so faster on my machine (its down to about .5s now). Nothing
                        revolutionary, but I do notice the difference. Opening a window with
                        Cmd-n or with 'mvim' should be equally fast now.

                        Björn

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Nico Weber
                        ... Did you attach the patch? I can t see it. ... As long as quicklaunch is disabled :-) Nico --~--~---------~--~----~------------~-------~--~----~ You
                        Message 11 of 21 , Feb 11, 2009
                        • 0 Attachment
                          > Nico, I prepared a patch but I'd appreciate it if you'd look over it
                          > before I merge.

                          Did you attach the patch? I can't see it.

                          > As for startup times: with these patches startup is another 200ms or
                          > so faster on my machine (its down to about .5s now).  Nothing
                          > revolutionary, but I do notice the difference.  Opening a window with
                          > Cmd-n or with 'mvim' should be equally fast now.

                          As long as quicklaunch is disabled :-)

                          Nico
                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • björn
                          ... Geez...I _was_ a bit tired when I posted that. Here we go again (still tired, but lets hope I get it right). Björn
                          Message 12 of 21 , Feb 11, 2009
                          • 0 Attachment
                            2009/2/11 Nico Weber <nicolasweber@...>:
                            >
                            >> Nico, I prepared a patch but I'd appreciate it if you'd look over it
                            >> before I merge.
                            >
                            > Did you attach the patch? I can't see it.

                            Geez...I _was_ a bit tired when I posted that. Here we go again
                            (still tired, but lets hope I get it right).

                            Björn

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Nico Weber
                            ... Alright, I took a short look at this. First a few comments just from looking at the diffs: I m not sure about this part: - -#ifdef MACOS_X - /* os x
                            Message 13 of 21 , Feb 17, 2009
                            • 0 Attachment
                              >>> Nico, I prepared a patch but I'd appreciate it if you'd look over it
                              >>> before I merge.
                              >>
                              >> Did you attach the patch? I can't see it.
                              >
                              > Geez...I _was_ a bit tired when I posted that. Here we go again
                              > (still tired, but lets hope I get it right).


                              Alright, I took a short look at this.

                              First a few comments just from looking at the diffs:

                              I'm not sure about this part:

                              -
                              -#ifdef MACOS_X
                              - /* os x doesn't really support fork(), so we can't fork of a
                              gui
                              - * in an already running vim. see gui_start() for more details.
                              - */
                              - gui.dofork = FALSE;
                              -#endif

                              iirc, this made sure -f is ignored if passed to `:gui` as documented a
                              `:h :gui`. It should probably stay in. Ah, wait, you don't define
                              MAY_FORK on OS X at all, so this _can_ probably stay out. Just take
                              another look if that's true :-)



                              +#ifdef MACOS_X
                              + if (gui.dofork)
                              + macosx_fork();
                              +#endif
                              +

                              Add a "/* does not return */" comment to the call to macosx_fork().



                              + * Kinda sucks to restart vim when doing :gui, so don't fork in
                              that
                              + * case (make sure gui.dofork is only set when interpreting argv,
                              not
                              + * when doing :gui. Currently, gui.dofork is set to false in
                              ex_gui().

                              The "restart" part is no longer really true. And this part of the
                              comment should perhaps be in gui.c, possibly in ex_gui(). Also, a
                              closing paren is missing :-P



                              + * Also doesn't work well if vim starts cscope (or some other
                              + * subprocess I guess), because it's not transferred to the newly
                              + * exec'd process, leaving an orphaned process (not a zombie
                              process)
                              + * behind. The Right Thing is to kill all our child processes
                              before
                              + * calling exec.

                              This is no longer true too, because we now fork before cscope and
                              friends are started. You can probably just delete this paragraph.


                              Now some testing…hm, looks as if weird things happen if I start MacVim
                              in terminal mode (`build/Release/MacVim.app/Contents/MacOS/Vim`). You
                              probably need to check if gui mode should be started in main, like this:

                              + if (gui.starting && gui.dofork)
                              + macosx_fork();

                              That seems to fix this particular problem. I can't find other problems
                              (at least not no new ones: If you start in terminal mode, then do
                              `:gui`, then hit ctrl-z in terminal, followed by `bg`, and then close
                              the terminal, you get a DEAD_PROCESS in console, but that does
                              currently happen too, and is not really a problem anyway). I didn't
                              try _very_ hard, but I guess the patch is good enough for wider testing.

                              Nico
                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • björn
                              ... Yeah, it should all be ok the way it stands. I fixed all the comments as well (and added some new ones in gui.c). ... Ah. Good catch. ... Yeah, I don t
                              Message 14 of 21 , Feb 18, 2009
                              • 0 Attachment
                                2009/2/18 Nico Weber:
                                >
                                > Alright, I took a short look at this.
                                >
                                > First a few comments just from looking at the diffs:
                                >
                                > I'm not sure about this part:
                                >
                                > -
                                > -#ifdef MACOS_X
                                > - /* os x doesn't really support fork(), so we can't fork of a
                                > gui
                                > - * in an already running vim. see gui_start() for more details.
                                > - */
                                > - gui.dofork = FALSE;
                                > -#endif
                                >
                                > iirc, this made sure -f is ignored if passed to `:gui` as documented a
                                > `:h :gui`. It should probably stay in. Ah, wait, you don't define
                                > MAY_FORK on OS X at all, so this _can_ probably stay out. Just take
                                > another look if that's true :-)

                                Yeah, it should all be ok the way it stands.

                                I fixed all the comments as well (and added some new ones in gui.c).

                                > Now some testing…hm, looks as if weird things happen if I start MacVim
                                > in terminal mode (`build/Release/MacVim.app/Contents/MacOS/Vim`). You
                                > probably need to check if gui mode should be started in main, like this:
                                >
                                > + if (gui.starting && gui.dofork)
                                > + macosx_fork();
                                >
                                > That seems to fix this particular problem. I can't find other problems

                                Ah. Good catch.

                                > (at least not no new ones: If you start in terminal mode, then do
                                > `:gui`, then hit ctrl-z in terminal, followed by `bg`, and then close
                                > the terminal, you get a DEAD_PROCESS in console, but that does
                                > currently happen too, and is not really a problem anyway).

                                Yeah, I don't know if I even can be bothered doing anything about this...(?)

                                > I didn't
                                > try _very_ hard, but I guess the patch is good enough for wider testing.

                                Thanks for going over it! I made the modifications you suggested and
                                pushed it to the public repo. I'll let it sit there until the weekend
                                and then I'll build a new snapshot.

                                Björn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Gary Norton
                                ... Sorry to revive an old post, but I am seeing this error with build 7.2.shapshot52_1 which was built via MacPorts. From looking at the repo, this seems like
                                Message 15 of 21 , May 5, 2010
                                • 0 Attachment
                                  björn-11 wrote:
                                  >
                                  > Ah. Good catch.
                                  >
                                  >> (at least not no new ones: If you start in terminal mode, then do
                                  >> `:gui`, then hit ctrl-z in terminal, followed by `bg`, and then close
                                  >> the terminal, you get a DEAD_PROCESS in console, but that does
                                  >> currently happen too, and is not really a problem anyway).
                                  >
                                  > Yeah, I don't know if I even can be bothered doing anything about
                                  > this...(?)
                                  >
                                  >> I didn't
                                  >> try _very_ hard, but I guess the patch is good enough for wider testing.
                                  >
                                  > Thanks for going over it! I made the modifications you suggested and
                                  > pushed it to the public repo. I'll let it sit there until the weekend
                                  > and then I'll build a new snapshot.
                                  >
                                  > Björn
                                  >
                                  > --~--~---------~--~----~------------~-------~--~----~
                                  > You received this message from the "vim_mac" maillist.
                                  > For more information, visit http://www.vim.org/maillist.php
                                  > -~----------~----~----~----~------~----~------~--~---
                                  >

                                  Sorry to revive an old post, but I am seeing this error with build
                                  7.2.shapshot52_1 which was built via MacPorts. From looking at the repo,
                                  this seems like the most recent.

                                  I experienced the error when launching git commit if it's of any value.

                                  Do I have the wrong build, or is there something else I need to do?
                                  --
                                  View this message in context: http://old.nabble.com/mvim-on-file-with-path-tp21793284p28466368.html
                                  Sent from the Vim - Mac mailing list archive at Nabble.com.

                                  --
                                  You received this message from the "vim_mac" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php
                                • björn
                                  ... Please try out the official snapshot build [1] and see if that works first. If that also has this problem then go through the steps listed at [2]. If
                                  Message 16 of 21 , May 5, 2010
                                  • 0 Attachment
                                    On 5 May 2010 16:56, Gary Norton <gary.norton@...> wrote:
                                    >
                                    > Sorry to revive an old post, but I am seeing this error with build
                                    > 7.2.shapshot52_1 which was built via MacPorts. From looking at the repo,
                                    > this seems like the most recent.
                                    >
                                    > I experienced the error when launching git commit if it's of any value.
                                    >
                                    > Do I have the wrong build, or is there something else I need to do?

                                    Please try out the official snapshot build [1] and see if that works
                                    first. If that also has this problem then go through the steps listed
                                    at [2]. If you're still having problems, let me know and I'll look
                                    into it.

                                    Björn


                                    [1] http://code.google.com/p/macvim/wiki/Snapshot
                                    [2] http://code.google.com/p/macvim/wiki/ReportingBugs

                                    --
                                    You received this message from the "vim_mac" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php
                                  Your message has been successfully submitted and would be delivered to recipients shortly.