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

Re: Win32-gvimext.dll: Bug or Feature?

Expand Messages
  • Walter Briscoe
    In message of Wed, 24 Sep 2003 11:17:10 in , Matthias Mohr writes ... It is a feature of the
    Message 1 of 6 , Sep 24, 2003
    • 0 Attachment
      In message <000b01c3827c$a3594cc0$13011eac@...> of Wed, 24 Sep 2003
      11:17:10 in , Matthias Mohr <MMohr@...> writes
      >Hi,
      >
      >I don't know if this is a bug of gvimext.dll or a feature.
      It is a feature of the win32 port of vim.
      >
      >If you select one file and then choose "Edit with vim" from right mouse menu,
      >it changes the default directory to the directory of that file and then
      >opens it.
      >
      >If you select more than one file and then choose "Edit with single vim" or
      >"Diff with vim" it does not change the default directory and opens the file.
      >The default working directory is then "C:\" which confuses me always :-)
      >
      >Is this behaviour correct? If yes, why?
      :help win32_curdir documents the behaviour. Some time ago, I complained
      unsuccessfully about it. It was not so big a deal to change it in my
      local copy. It is more irritating when vim is called from the command
      line. Unfortunately, neither Bram nor I knew how to distinguish that
      case. It has to be possible (at least in NTX). www.sysinternals.com's
      Process Explorer 6.03 shows a process tree but but no source code.
      --
      Walter Briscoe
    • Douglas E Cook
      ... I m not sure I understand what you re saying. What cases are you trying to distinguish between? Do you just want to find out the name/PID of your parent
      Message 2 of 6 , Sep 24, 2003
      • 0 Attachment
        > :help win32_curdir documents the behaviour. Some time ago, I
        > complained
        > unsuccessfully about it. It was not so big a deal to change it in
        > my
        > local copy. It is more irritating when vim is called from the
        > command
        > line. Unfortunately, neither Bram nor I knew how to distinguish
        > that
        > case. It has to be possible (at least in NTX).
        > www.sysinternals.com's
        > Process Explorer 6.03 shows a process tree but but no source code.

        I'm not sure I understand what you're saying. What cases are you trying
        to distinguish between?

        Do you just want to find out the name/PID of your parent process? If so,
        here's the scoop:

        It isn't particularly simple, and it isn't "documented" per se.
        Officially, Win32 maintains NO parent/child relationship between
        processes. There is no documented interface to directly get the parent
        or children of a particular process. However, the information doesn't
        get thrown away and there are some "helper" DLLs that are part of Windows
        debugging support that can be used to discover this information.

        If this is worthwhile, I can dig up some code that will implement "get
        parent process name" or "get parent process id".

        As an alternative, you could have gvimext.dll use some alternative signal
        that gvim would recognize -- an extra parameter on the command line, an
        environment variable, or any number of other IPC mechanisms.

        ________________________________________________________________
        The best thing to hit the internet in years - Juno SpeedBand!
        Surf the web up to FIVE TIMES FASTER!
        Only $14.95/ month - visit www.juno.com to sign up today!
      • Walter Briscoe
        In message of Wed, 24 Sep 2003 14:07:16 in , Douglas E Cook writes ... [snip] ... I was
        Message 3 of 6 , Sep 24, 2003
        • 0 Attachment
          In message <20030924.140717.904.0.douglascook@...> of Wed, 24 Sep
          2003 14:07:16 in , Douglas E Cook <douglascook@...> writes
          >> :help win32_curdir documents the behaviour.
          [snip]
          >> Process Explorer 6.03 shows a process tree but but no source code.
          >
          I was hopeful that someone would byte on my provocative posting. ;-)

          >I'm not sure I understand what you're saying. What cases are you trying
          >to distinguish between?
          Bram can answer that better than I.

          >
          >Do you just want to find out the name/PID of your parent process? If so,
          >here's the scoop:
          I see two issues here: how does one identify the parentage of processes
          including that of the current process as a particular case and what
          circumstances does Bram want to stimulate changing the current
          directory. I am interested in the first issue in any case.

          >
          >It isn't particularly simple, and it isn't "documented" per se.
          >Officially, Win32 maintains NO parent/child relationship between
          >processes. There is no documented interface to directly get the parent
          >or children of a particular process. However, the information doesn't
          >get thrown away and there are some "helper" DLLs that are part of Windows
          >debugging support that can be used to discover this information.
          Douglas frightens me with those words. I would like details. I can use
          an original W95 system to check the portability of capabilities.

          >
          >If this is worthwhile, I can dig up some code that will implement "get
          >parent process name" or "get parent process id".
          Please may I see both.

          >
          >As an alternative, you could have gvimext.dll use some alternative signal
          >that gvim would recognize -- an extra parameter on the command line, an
          >environment variable, or any number of other IPC mechanisms.
          The code in question is in g\{0,1\)vim.exe rather than gvimext.dll.
          There are several scenarios where explorer opens a single file without
          the current directory being set to anything useful (or predictable?).
          (I found :pwd was C:\ when I opened two files in F: with a single vim.)
          For example, I might associate vim.exe with .txt files and double click
          a .txt file. I believe Bram may like to set the current working
          directory from the first file if opened by explorer and that inability
          to determine "opened by explorer" results in the current behaviour.

          I will do research if Douglas details his knowledge; as always, Bram may
          veto my suggestions.
          --
          Walter Briscoe
        • Matthias Mohr
          ... As far as I understood, he wants to distinguish between the calling of gvim from Explorer (gvimext) and from command line. Here is how I think it should
          Message 4 of 6 , Sep 25, 2003
          • 0 Attachment
            > > :help win32_curdir documents the behaviour. Some time ago, I
            > > complained
            > > unsuccessfully about it. It was not so big a deal to change it in
            > > my
            > > local copy. It is more irritating when vim is called from the
            > > command
            > > line. Unfortunately, neither Bram nor I knew how to distinguish
            > > that
            > > case. It has to be possible (at least in NTX).
            > > www.sysinternals.com's
            > > Process Explorer 6.03 shows a process tree but but no source code.
            >
            > I'm not sure I understand what you're saying. What cases are you trying
            > to distinguish between?
            As far as I understood, he wants to distinguish between the calling of gvim
            from Explorer (gvimext) and from command line.

            Here is how I think it should work:
            - when gvim will be called indirectly from gvimext with one file or with
            more than one file from same directory it should change his working
            directory to that directory.
            - when using gvim via command line it should keep his working directory
            to the one where it was started and do not change it (neither with
            one nor with more than one file).

            Making this possible should be really easy.
            Just add an additional command line parameter to vim, telling him to
            change the working directory.
            Then let gvimext choose if the selected files are from same directory and
            then start gvim with the new parameter (or not if they come from different
            directories.
            If you want the same behaviour from command line calling, you can always
            add that parameter (or maybe we could define a configuration variable)

            I didn't understand for what you need the name or PID of your parent
            process!?
            This confuses me... :-)

            with regards,
            Matthias

            Von der Vision zur Mission
            Unter diesem Motto findet am 30.09.2003 von 14.00 bis 18.00 Uhr ein Kompetenzforum mit Fachvortraegen der Virtuellen Fabrik Baden-Wuerttemberg an der IHK Ravensburg-Weingarten statt. Im Rahmen des Kompetenzforums wird sich auch SysDesign praesentieren. Weitere Informationen zur Veranstaltung finden Sie unter:
            http://www.sysdesign-edv.com/content/04/ge/messen_inhalt3.htm
          • Douglas E Cook
            ... I ll look it up, just for satisfaction of curiosity. However, from what I understand of the problem, the correct solution in this case would be to change
            Message 5 of 6 , Sep 25, 2003
            • 0 Attachment
              > >If this is worthwhile, I can dig up some code that will implement
              > "get
              > >parent process name" or "get parent process id".
              > Please may I see both.

              I'll look it up, just for satisfaction of curiosity. However, from what
              I understand of the problem, the correct solution in this case would be
              to change gvimext.dll to notify gvim of the special case, not modify
              gvim.exe to try to guess about the situation.

              ________________________________________________________________
              The best thing to hit the internet in years - Juno SpeedBand!
              Surf the web up to FIVE TIMES FASTER!
              Only $14.95/ month - visit www.juno.com to sign up today!
            Your message has been successfully submitted and would be delivered to recipients shortly.