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

feature-request: USER_VIMRC, SYSTEM_VIMRC, USER_PLUGIN_DIR, SYSTEM_PLUGIN_DIR

Expand Messages
  • Yakov Lerner
    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
    Message 1 of 5 , Oct 3, 2004
    • 0 Attachment
      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.

      Thanks
      Yakov
    • Dave Silvia
      I understand an sympathize completely! Things can get to a state where they are best served up with a generous portion of Ragu(R). I don t, however,
      Message 2 of 5 , Oct 3, 2004
      • 0 Attachment
        I understand an sympathize completely! Things can get to a state where they
        are best served up with a generous portion of Ragu(R).

        I don't, however, completely understand the 'if(win32)' reference. The name
        of the vimrc file is convention, not dictate. Either can exist on either
        platform (or any platform I know of).

        As far as system/user plugin dirs, don't they already exist? (please,
        forgive my ignorance, I only came on board in June with the vim63 release).
        $VIMRUNTIME is where the system stuff goes. The plugin, indent, syntax, etc
        directories and files for the distribution are there. And runtimepath has
        all the other locations to search for possibilities for appropriate files.

        So, the system plugins are in $VIMRUNTIME/plugin while user plugins are in
        any other plugin directory in runtimepath.

        For example, one directory in runtimepath is $VIMRUNTIME/../vimfiles. I put
        my filetype.vim there and my mupad.vim specific files in
        ftplugin/syntax/indent as appropriate to the file's function. I have all my
        authored and downloaded plugins in the plugin directory there as well as
        having copied $VIMRUNTIME/macros/matchit.vim to this directory. I also have
        my syncolor.vim override file in $VIMRUNTIME/../vimfiles/after/syntax

        If I had so desired, I could have chosen ~/vimfiles for the same purpose, it
        being automagically included in runtimepath. This would have been
        ultimately user specific.

        If I were setting up a system for multi-users, the breakdown would be:

        $VIMRUNTIME all distribution
        $VIMRUNTIME../vimfiles all system wide user non-distribution
        ~/vimfiles individual user files.

        Of course, there may/can be platform convention differences, but, as I said
        earlier, these are only convention. The major difference in the default
        runtimepath seems only to be that in ~/ the files are conventionally kept in
        a .vim directory on UNIX platforms (it doesn't _have_ to be so, it could
        also be vimfiles, just add that to runtimepath systemwide).

        Is there something I'm missing or am I being terribly naïve?

        thx,
        Dave S.

        *** -----Original Message-----
        *** From: Yakov Lerner [mailto:qlerner@...]
        *** Sent: Sunday, October 03, 2004 4:47 AM
        *** To: vim-dev@...; vim@...
        *** Subject: feature-request: USER_VIMRC, SYSTEM_VIMRC, USER_PLUGIN_DIR,
        *** SYSTEM_PLUGIN_DIR
        ***
        ***
        *** 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.
        ***
        *** Thanks
        *** Yakov
        ***
        ***
      • 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 3 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 4 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 5 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.