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

Re: mvim on file with path

Expand Messages
  • björn
    ... I ve not run across this problem before and I cannot reproduce on my machine. The first step is always to move your .[g]vimrc files and the .vim directory
    Message 1 of 21 , Feb 2, 2009
    • 0 Attachment
      2009/2/2 alexanderkahn:
      >
      > Hopefully this isn't an often-asked question: When I run `mvim sti/
      > sites/default/settings.php` for example, MacVim starts up with a blank
      > screen saying "sti/sites/default/settings.php New DIRECTORY". For some
      > reason, it thinks I supplied a directory path on the command line but
      > actually I specified a file that exists. When I supply an absolute
      > path, for example by prepending the above path with '~', MacVim loads
      > up the file correctly. Why is this? Am I using an outdated mvim
      > script? Am I using it incorrectly? Thanks for any assistance.

      I've not run across this problem before and I cannot reproduce on my
      machine. The first step is always to move your .[g]vimrc files and
      the .vim directory out of the way and see if they may be causing the
      problem. Let me know how that goes.

      Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • alexanderkahn
      ... Moving out my .[g]vimrc files and .vim directory fixed the problem. I isolated the issue to the option autochdir . Removing this option from my .vimrc
      Message 2 of 21 , Feb 4, 2009
      • 0 Attachment
        On Feb 2, 1:58 pm, björn <bjorn.winck...@...> wrote:

        > I've not run across this problem before and I cannot reproduce on my
        > machine.  The first step is always to move your .[g]vimrc files and
        > the .vim directory out of the way and see if they may be causing the
        > problem.  Let me know how that goes.
        >
        > Björn

        Moving out my .[g]vimrc files and .vim directory fixed the problem. I
        isolated the issue to the option 'autochdir'. Removing this option
        from my .vimrc made mvim work as expected with relative file paths.
        With autochdir in your .vimrc, can you reproduce the problem? Any
        guess as to why the option would cause this problem?

        Thanks,
        Alex
        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... Ok, I can reproduce the problem now. I ll see if I can figure out what s going on. I wonder though: is this option only broken in MacVim? Björn
        Message 3 of 21 , Feb 4, 2009
        • 0 Attachment
          2009/2/4 alexanderkahn:
          >
          > Moving out my .[g]vimrc files and .vim directory fixed the problem. I
          > isolated the issue to the option 'autochdir'. Removing this option
          > from my .vimrc made mvim work as expected with relative file paths.
          > With autochdir in your .vimrc, can you reproduce the problem? Any
          > guess as to why the option would cause this problem?

          Ok, I can reproduce the problem now. I'll see if I can figure out
          what's going on. I wonder though: is this option only broken in
          MacVim?

          Björn

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • björn
          ... 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
          Message 4 of 21 , Feb 4, 2009
          • 0 Attachment
            2009/2/4 björn:
            > 2009/2/4 alexanderkahn:
            >>
            >> Moving out my .[g]vimrc files and .vim directory fixed the problem. I
            >> isolated the issue to the option 'autochdir'. Removing this option
            >> from my .vimrc made mvim work as expected with relative file paths.
            >> With autochdir in your .vimrc, can you reproduce the problem? Any
            >> guess as to why the option would cause this problem?
            >
            > Ok, I can reproduce the problem now. I'll see if I can figure out
            > what's going on. I wonder though: is this option only broken in
            > MacVim?

            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, ...?).

            Björn

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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.