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

Re: _vimrc not run when invoking gvim on text file from context menu

Expand Messages
  • Paul
    ... I should clarify that it is the user-specific environment variable VIMINIT in Windows that I set above. However, it isn t the greatest solution. This
    Message 1 of 7 , Feb 21, 2013
    • 0 Attachment
      >On Feb 21, 12:54 pm, Paul <paul.domas...@...> wrote:
      > In Windows 7, I got a program "pinned" to the taskbar. It is
      > basically a shortcut with the "Target" field set to:
      >
      > "C:\Program Files (x86)\Vim\vim73\gvim.exe" -u _vimrc
      >
      > and the "Start in" field set to $USERPROFILE. The _vimrc is also in
      > $USERPROFILE, so it runs when gvim is started.
      >
      > However, when I right click on a text file in Windows Explorer and
      > choose "Edit with vim", _vimrc is not run. Is something I can do to
      > have it run?
      >
      > There are restrictions that a solution would have to observe. First
      > is that I don't have admin privileges, so I can only stick _vimrc in
      > places where $USERNAME can write. Also, $HOME is not a good place
      > for it because it is set to a network drive. Finally, since I'm
      > invoking gvim from the context menu, I'm not aware of a way to set
      > environment variables for such an invocation of vim (unlike the case
      > invoking vim from a script or command line).


      On Feb 21, 1:05 pm, Paul <paul.domas...@...> wrote:
      > I found the solution after a simple read of ":help vimrc". Set the
      > environment variable VIMINIT to
      >
      > source $USERPROFILE\_vimrc
      >
      > For any other system or computing environment, I strongly suspect
      > that one can use whatever path is to your _vimrc if it isn't
      > $USERPROFILE \_vimrc.

      I should clarify that it is the user-specific environment variable
      VIMINIT in Windows that I set above.

      However, it isn't the greatest solution. This environment variable
      propagates where one does not expect. For example, it propagates to
      cygwin's bash, which causes problems when one invokes gvim from the
      bash command line. The installation of gvim being invoked from bash
      is different from the Windows installation of gvim, and the path
      $USERPROFILE/_vimrc doesn't work because $USERPROFILE uses Windows
      path notation. The solution (being validated) is to set VIMINIT
      explicitly in the bashrc file.

      --
      --
      You received this message from the "vim_use" 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

      ---
      You received this message because you are subscribed to the Google Groups "vim_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Jürgen Krämer
      Hi, ... the $HOME variable is the culprit. If you don t give the -u parameter on the command line Vim looks for its _vimrc in the directory defined by $HOME.
      Message 2 of 7 , Feb 21, 2013
      • 0 Attachment
        Hi,

        Paul wrote:
        >
        > In Windows 7, I got a program "pinned" to the taskbar. It is
        > basically a shortcut with the "Target" field set to:
        >
        > "C:\Program Files (x86)\Vim\vim73\gvim.exe" -u _vimrc
        >
        > and the "Start in" field set to $USERPROFILE. The _vimrc is also in
        > $USERPROFILE, so it runs when gvim is started.
        >
        > However, when I right click on a text file in Windows Explorer and
        > choose "Edit with vim", _vimrc is not run. Is something I can do to
        > have it run?
        >
        > There are restrictions that a solution would have to observe. First
        > is that I don't have admin privileges, so I can only stick _vimrc in
        > places where $USERNAME can write. Also, $HOME is not a good place for
        > it because it is set to a network drive. Finally, since I'm invoking
        > gvim from the context menu, I'm not aware of a way to set environment
        > variables for such an invocation of vim (unlike the case invoking vim
        > from a script or command line).

        the $HOME variable is the culprit. If you don't give the -u parameter on
        the command line Vim looks for its _vimrc in the directory defined by
        $HOME. On Windows, if $HOME does not exist it is constructed internally
        from $HOMEDRIVE$HOMEPATH (see ":help $HOME").

        So either you have to put your _vimrc on the network drive given by
        $HOME, or you have to modify the command that is executed when you click
        on "Edit with vim".

        I have never used this context menu entry much and for the only computer
        that has it I'm not so sure if I haven't tinkered around with it, so the
        following might be of no help:

        - Open the registry editor by executing regedit.exe.
        - Search for the Text "Edit with Vim". If one of the letters in the
        context menu is underlined put an ampersand in front of it, e.g. I
        had to actually search for "Edit with &Vim".
        - You should find an entry with an sub-entry called "Command". This
        sub-entry should have a key called "(Standard)" or "(Default)" or
        something like this which holds the command to start Vim.
        - Modify it so that it includes "-u $USERPROFILE\.vimrc" after the
        program name, i.e. it should like

        <Path to Vim>\Vim.exe -u $USERPROFILE\.vimrc "%1"

        Instead of "%1" you can also write "%L" which might be better for
        long file names.

        Hope this helps.

        Regards,
        Jürgen

        --
        Sometimes I think the surest sign that intelligent life exists elsewhere
        in the universe is that none of it has tried to contact us. (Calvin)

        --
        --
        You received this message from the "vim_use" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Paul
        ... Thanks for that, Jurgen. I don t have the ability to change the registry. However, I found that setting the user-specific Windows environment variable
        Message 3 of 7 , Feb 22, 2013
        • 0 Attachment
          On Feb 22, 2:52 am, Jürgen Krämer <jottka...@...> wrote:
          >Paul wrote:
          >> In Windows 7, I got a program "pinned" to the taskbar. It is
          >> basically a shortcut with the "Target" field set to:
          >>
          >> "C:\Program Files (x86)\Vim\vim73\gvim.exe" -u _vimrc
          >>
          >> and the "Start in" field set to $USERPROFILE. The _vimrc is also
          >> in $USERPROFILE, so it runs when gvim is started.
          >>
          >> However, when I right click on a text file in Windows Explorer and
          >> choose "Edit with vim", _vimrc is not run. Is something I can do
          >> to have it run?
          >>
          >> There are restrictions that a solution would have to observe.
          >> First is that I don't have admin privileges, so I can only stick
          >> _vimrc in places where $USERNAME can write. Also, $HOME is not a
          >> good place for it because it is set to a network drive. Finally,
          >> since I'm invoking gvim from the context menu, I'm not aware of a
          >> way to set environment variables for such an invocation of vim
          >> (unlike the case invoking vim from a script or command line).
          >
          > the $HOME variable is the culprit. If you don't give the -u
          > parameter on the command line Vim looks for its _vimrc in the
          > directory defined by $HOME. On Windows, if $HOME does not exist it
          > is constructed internally from $HOMEDRIVE$HOMEPATH (see ":help
          > $HOME").
          >
          > So either you have to put your _vimrc on the network drive given by
          > $HOME, or you have to modify the command that is executed when you
          > click on "Edit with vim".
          >
          > I have never used this context menu entry much and for the only
          > computer that has it I'm not so sure if I haven't tinkered around
          > with it, so the following might be of no help:
          >
          >
          > - Open the registry editor by executing regedit.exe.
          > - Search for the Text "Edit with Vim". If one of the letters in the
          > context menu is underlined put an ampersand in front of it, e.g.
          > I had to actually search for "Edit with &Vim".
          > - You should find an entry with an sub-entry called "Command".
          > This sub-entry should have a key called "(Standard)" or
          > "(Default)" or something like this which holds the command to
          > start Vim.
          > - Modify it so that it includes "-u $USERPROFILE\.vimrc" after the
          > program name, i.e. it should like
          >
          > <Path to Vim>\Vim.exe -u $USERPROFILE\.vimrc "%1"
          >
          > Instead of "%1" you can also write "%L" which might be better for
          > long file names.

          Thanks for that, Jurgen.

          I don't have the ability to change the registry.

          However, I found that setting the user-specific Windows environment
          variable VIMINIT works. However, one has to be careful about the fact
          that all subprocesses inherit this. For example, if you run cygwin's
          bash shell, it will also inherit this. However, cygwin's bash uses
          posix style paths, so if VIMINIT contains DOS style paths, it will
          cause problems. As I said, my solution was to unset VIMINIT in my
          bash startup file ".bashrc". It's messy, having to undo something in
          one environment that was setup in another environment, but it's the
          nature of using global variables.

          --
          --
          You received this message from the "vim_use" 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

          ---
          You received this message because you are subscribed to the Google Groups "vim_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ben Fritz
          ... How about putting a very bare-bones .vimrc in $HOME, which just sets the runtimepath to somewhere else (local) and then sources your local .vimrc. You
          Message 4 of 7 , Feb 22, 2013
          • 0 Attachment
            On Thursday, February 21, 2013 11:54:07 AM UTC-6, Paul wrote:
            > There are restrictions that a solution would have to observe. First
            >
            > is that I don't have admin privileges, so I can only stick _vimrc in
            >
            > places where $USERNAME can write. Also, $HOME is not a good place for
            >
            > it because it is set to a network drive.

            How about putting a very bare-bones .vimrc in $HOME, which just sets the runtimepath to somewhere else (local) and then sources your local .vimrc. You could even detect Windows vs. Unix/Cygwin and do something different for each.

            --
            --
            You received this message from the "vim_use" 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

            ---
            You received this message because you are subscribed to the Google Groups "vim_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Paul
            ... My apologies for the long overdue response. Thanks, but the problem with putting a bare .vimrc at $HOME is that I m not always connected to the network.
            Message 5 of 7 , Mar 27 4:58 PM
            • 0 Attachment
              On Feb 22, 1:14 pm, Ben Fritz <fritzophre...@...> wrote:
              > On Thursday, February 21, 2013 11:54:07 AM UTC-6, Paul wrote:
              > > There are restrictions that a solution would have to observe.  First
              >
              > > is that I don't have admin privileges, so I can only stick _vimrc in
              >
              > > places where $USERNAME can write.  Also, $HOME is not a good place for
              >
              > > it because it is set to a network drive.
              >
              > How about putting a very bare-bones .vimrc in $HOME, which just sets the runtimepath to somewhere else (local) and then sources your local .vimrc. You could even detect Windows vs. Unix/Cygwin and do something different for each.

              My apologies for the long overdue response. Thanks, but the problem
              with putting a bare .vimrc at $HOME is that I'm not always connected
              to the network. I managed to solve the problem by setting $VIMINIT as
              a Windows environment variable.

              --
              --
              You received this message from the "vim_use" 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

              ---
              You received this message because you are subscribed to the Google Groups "vim_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            Your message has been successfully submitted and would be delivered to recipients shortly.