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

Re: feature-request: USER_VIMRC, SYSTEM_VIMRC, USER_PLUGIN_DIR, SYSTEM_PLUGIN_DIR

Expand Messages
  • Bram Moolenaar
    ... This is actually an idea that has been in the back of my head for a while. I tried explaining in the Vim tutorial how to find out where your vimrc file is
    Message 1 of 5 , Oct 3, 2004
    • 0 Attachment
      Yakov Lerner wrote:

      > This is the feature request that I wanted to post long ago. Maybe now is
      > ripe time to post this because vim7, with many new additions, is in the
      > works.
      > Here is the request:
      >
      > Have four global vim variables that automatically map to the (1) full
      > pathname of
      > personal vimrc file (2) system-wide vimrc file (3) personal plugin dir
      > (4) system-wide plugins dir.
      >
      > I'm posting this request because the tests like
      > if(win32) let x="_vimrc" else let x=".vimrc"
      > have several drawbacks: (1) they don't seem to cover all OSes, only two
      > most widespread ones
      > (2) they make explanations cumbersone (3) the rules seems to become more
      > and more
      > complicated every several years.
      >
      > It's easier to understand ":e $USER_VIMRC" or ":e &user_vimrc" that
      > works on any OS.

      This is actually an idea that has been in the back of my head for a
      while. I tried explaining in the Vim tutorial how to find out where
      your vimrc file is located, using ":scriptnames". That is clumsy,
      ":edit $VIMRC" could work.

      The location of the plugin directory is a bit more complicated, since it
      depends on the value of 'runtimepath'. Perhaps it can be the first
      directory in 'runtimepath' that exists.

      The only drawback is that when someone starts using Vim on a newly
      installed system there is no vimrc or plugin directory yet, and the
      variables won't direct you to where they should be placed. I'm not sure
      it's possible to set the variables to a recommended location then.

      --
      hundred-and-one symptoms of being an internet addict:
      56. You leave the modem speaker on after connecting because you think it
      sounds like the ocean wind...the perfect soundtrack for "surfing the net".

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
    • Yakov Lerner
      ... I m sure it s possible to set the variables to a recommended location. If the advanced user prefers some nonstandard, other than compiled-in
      Message 2 of 5 , Oct 3, 2004
      • 0 Attachment
        Bram Moolenaar wrote:

        >Yakov Lerner wrote:
        >
        >
        >> Have four global vim variables that automatically map to the (1) full
        >>pathname of
        >> personal vimrc file (2) system-wide vimrc file (3) personal plugin dir
        >>(4) system-wide plugins dir.
        >>
        >>I'm posting this request because the tests like
        >> if(win32) let x="_vimrc" else let x=".vimrc"
        >>have several drawbacks: (1) they don't seem to cover all OSes, only two
        >>most widespread ones
        >>(2) they make explanations cumbersone (3) the rules seems to become more
        >>and more
        >>complicated every several years.
        >>
        >>It's easier to understand ":e $USER_VIMRC" or ":e &user_vimrc" that
        >>works on any OS.
        >>
        >>
        >
        >This is actually an idea that has been in the back of my head for a
        >while. I tried explaining in the Vim tutorial how to find out where
        >your vimrc file is located, using ":scriptnames". That is clumsy,
        >":edit $VIMRC" could work.
        >
        >The only drawback is that when someone starts using Vim on a newly
        >installed system there is no vimrc or plugin directory yet, and the
        >variables won't direct you to where they should be placed. I'm not sure
        >it's possible to set the variables to a recommended location then.
        >
        >
        I'm sure it's possible to set the variables to a recommended location.
        If the "advanced"
        user prefers some nonstandard, other than compiled-in ~/.vim/plugins
        for his plugins, then he can
        surely personally refedine his own $MYPLUGINS in his .vimrc. I'd say
        $MYPLUGINS shall still
        intially point to ~/.vim/plugins even if the directory doesn't yet
        exist. Or, $SYSVIMRC can have this:
        if ! isdirectory("$MYPLUGINS") | :call system("mkdir -p
        $MYPLUGINS") | endif
        Additionally, it would be really useful if vim installation process
        automatically create the ~/.vim/plugins directory
        (user's own plugins directory) automatically.

        Talking about unix and ~/.vimrc: I don't see why $VIMRC can't be
        "$HOME/.vimrc" whether this
        file exists or not. In both cases, ":edit $VIMRC" will have the expected
        result, no ? I don't really understand
        what's alternative that $VIMRC can be set to other than "$HOME/.vimrc",
        even if ~/.vimrc doesn't exist.

        On windows, I'd expect $VIMRC to be $HOME/_vimrc and $SYSVIMRC be
        $VIM/_vimrc
        The point being that $VIMRC is user-specific and $SYSVIMRC is
        system-wide (for all users, not
        user-specific). Even if $HOME/_vimrc doesn't exist, I think it's natural
        that $VIMRC is $HOME/_vimrc
        so that mere ":edit $VIMRC" would create it. But then there will be
        clear difference between editing
        ":e $SYSVIMRC" (for all users) vs ":e $VIMRC" (this user only).

        >The location of the plugin directory is a bit more complicated, since it
        >depends on the value of 'runtimepath'. Perhaps it can be the first
        >directory in 'runtimepath' that exists.
        >
        >
        But name like "~/.vim/plugins' is compiled into vim, so why be shy about
        it ?

        On one hand, it would be really useful if the vim installation process
        automatically create the ~/.vim/plugins
        directory (user's own plugins directory). This is based on my expeience:
        (1) it is easier to find existing directory than non-existing one (2) it
        saves user the inevitable "mkdir -p" command.

        Even if personal plugins directory doesn't yet exist, I don't see why
        $MYPLUGINS shall not point to
        it, given that $MYPLUGINS (user-specific) is differentiated from $SYSPLUGINS
        directory (plugins for all users).
        Ponting to the recommended location, it might be a basis for useful
        if ! isdirectory("$MYPLUGINS") | :call system("mkdir -p
        $MYPLUGINS") | endif
        line in generic vimrc file.

        Yakov
      • Antoine J. Mechelynck
        Yakov Lerner wrote: [...] ... [...] 1) On some systems such as Windows, there is a 2nd user vimrc location compiled-in (in this
        Message 3 of 5 , Oct 3, 2004
        • 0 Attachment
          Yakov Lerner <qlerner@...> wrote:
          [...]
          > Talking about unix and ~/.vimrc: I don't see why $VIMRC can't be
          > "$HOME/.vimrc" whether this
          > file exists or not. In both cases, ":edit $VIMRC" will have the
          > expected result, no ? I don't really understand
          > what's alternative that $VIMRC can be set to other than
          > "$HOME/.vimrc", even if ~/.vimrc doesn't exist.
          [...]

          1) On some systems such as Windows, there is a "2nd user vimrc" location
          compiled-in (in this case $VIM/_vimrc). Windows systems with no $HOME
          defined (usually Win 9x systems) use that. (On such systems, $VIM/vimrc is
          the "system" vimrc and $VIM/_vimrc is the "user" vimrc.)

          2) On multi-boot systems, one may want to keep a single vimrc with if has()
          statements in it. It can be called either _vimrc or .vimrc and (with the
          proper settings) both Windows vim and Unix vim will find it. Of course it
          must be on a filesystem readable by all concerned OSes, thus not an ext2 or
          ext3 filesystem if Windows is involved.

          3) When the -u command-line argument is used to direct vim to a
          "project-specific" vimrc, then $VIMRC should IMHO reflect that rather than
          the default location.

          Best regards,
          Tony.
        Your message has been successfully submitted and would be delivered to recipients shortly.