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

mvim on file with path

Expand Messages
  • alexanderkahn
    Hi, 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
    Message 1 of 21 , Feb 2, 2009
    • 0 Attachment
      Hi,

      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.

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