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

Re: Bug in :runtime ?

Expand Messages
  • Bill McCarthy
    ... not found in runtimepath : plugin ** *.vim ... In many cases Vim does work OK here. For example, if I ... I will get all *.c files in directories
    Message 1 of 10 , Jul 26 1:30 PM
    • 0 Attachment
      On Wed 26-Jul-06 1:07pm -0600, Benji Fisher wrote:


      > On Wed, Jul 26, 2006 at 07:45:12AM +0200, A.J.Mechelynck wrote:

      >> IIUC, it's a feature: \* means a literal asterisk. Not a very good
      >> feature since IIUC, asterisks are not allowed in filenames on Windows.
      >> Or can they happen in long file names?

      > Right, as explained under
      >
      > :help dos-backslash
      >
      > (There is not enough detail there to predict what vim will do in this
      > particular situation, though.) This might also work (but I am not going
      > to find a W32 box to test it, sorry):
      >
      > :ru! plugin\\**\\*.vim

      :verb ru! plugin\\**\\*.vim
      not found in 'runtimepath': "plugin\\**\\*.vim"

      > :help starstar-wildcard
      >
      > to explain using \**\ on DOS-like systems. In fact, after reading that,
      > it seems to me as though \**\ *should* be interpreted as path separator,
      > wildcard, path separator in this case.

      In many cases Vim does work OK here. For example, if I
      type:

      :args .\**\*.c

      I will get all *.c files in directories below the current
      (but no *.c files in current). Also,

      :args **\*.c

      does the same incorrect thing - at least it's consistent :-)

      OTOH, either of:

      :args ./**/*.c
      :args **/*.c

      find all the *.c files, including in the current, as
      expected.

      In just feels like a bug when it almost works in :args but
      produces an error in :runtime.

      BTW, until reading through the docs you mentioned, I thought

      args **\*.c

      returning everything below current, was a feature. If I
      needed all *.c in the current and below, I was typing:

      args *.c **\*.c

      How do you restrict to just the directories below current
      (without any shell tricks)?

      --
      Best regards,
      Bill
    • Bill McCarthy
      ... IMHO too many. One common example is passing a file to a program within Vim - the / appears to be treated like a switch in many windows programs. --
      Message 2 of 10 , Jul 26 1:40 PM
      • 0 Attachment
        On Wed 26-Jul-06 1:20pm -0600, A.J.Mechelynck wrote:

        > Morality: Whenever possible, use / as path separator in Vim, even on
        > Windows. There are a few exceptions (where they don't work).

        IMHO too many. One common example is passing a file to a
        program within Vim - the '/' appears to be treated like a
        switch in many windows programs.

        --
        Best regards,
        Bill
      • A.J.Mechelynck
        ... $HOME/vimfiles and $HOME/vimfiles/after should be in your rtp (on Windows); the first place where Vim looks for your _vimrc is $HOME even though it is
        Message 3 of 10 , Jul 26 3:03 PM
        • 0 Attachment
          Bill McCarthy wrote:
          > On Wed 26-Jul-06 12:45am -0600, A.J.Mechelynck wrote:
          >
          >> IIUC, it's a feature: \* means a literal asterisk. Not a very good
          >> feature since IIUC, asterisks are not allowed in filenames on Windows.
          >> Or can they happen in long file names?
          >
          > I know \* means a literal asterisk in a regex, but didn't
          > know it meant that in a file name. In fact I don't believe
          > that is true on Windows. For example,
          >
          > :arg .\*.c
          >
          > works as expected (like :arg *.c).
          >
          >>From your second point, AFAIK '*' is not valid in a
          > filename:
          >
          > [c:\pad]echo foo > "bar*"
          > 4NT: (Sys) The filename, directory name, or volume label syntax is incorrect.
          > "C:\pad\bar*"
          >
          >> ... Don't you have a HOME directory? On XP, I would expect that to
          >> default to %HOMEDRIVE%%HOME£PATH% if you don't define it (something like
          >> C:\Documents and Settings\<username> ) -- and, since XP is a multiuser
          >> OS, it allows each user to have a different set of preferences. $VIM,
          >> OTOH, would normally be something like C:\Program Files\Vim , which is
          >> the same for everyone.
          >
          > Yes, I have a HOME, but it is not in my rtp.
          >
          > :echo expand("~")
          > c:\util\home
          >
          > :echo $vim $vimruntime
          > c:\vim c:\vim\vim70
          >
          > But since I'm the only user of Vim/Gvim on this machine or
          > my home network, I don't take advantage of per user
          > settings.
          >

          $HOME/vimfiles and $HOME/vimfiles/after should be in your 'rtp' (on
          Windows); the first place where Vim looks for your _vimrc is $HOME even
          though it is not in 'rtp'. (And BTW, $VIM should not be in your 'rtp'
          either; but $VIM/vimfiles and $VIM/vimfiles/after -- and $VIMRUNTIME
          which, on version 7.0, is $VIM/vim70 -- should.)

          Yeah, and some day you'll activate the "Guest" user for your
          eight-years-old precocious nephew, or someone... Well, it's your funeral.


          Best regards,
          Tony.
        • Bill McCarthy
          ... From :h starting Recommended place for your personal initializations: MS-DOS and Win32 $HOME/_vimrc or $VIM/_vimrc I use the second choice. In an office
          Message 4 of 10 , Jul 26 3:45 PM
          • 0 Attachment
            On Wed 26-Jul-06 5:03pm -0600, A.J.Mechelynck wrote:

            > $HOME/vimfiles and $HOME/vimfiles/after should be in your 'rtp' (on
            > Windows); the first place where Vim looks for your _vimrc is $HOME even
            > though it is not in 'rtp'. (And BTW, $VIM should not be in your 'rtp'
            > either; but $VIM/vimfiles and $VIM/vimfiles/after -- and $VIMRUNTIME
            > which, on version 7.0, is $VIM/vim70 -- should.)

            From :h starting

            Recommended place for your personal initializations:
            MS-DOS and Win32 $HOME/_vimrc or $VIM/_vimrc

            I use the second choice.

            In an office environment I do use the $home directory for
            all personalizations. But at home, I find it more
            convenient to not do this - nor do I rely on automatic
            assignment of $home (this can lead to using embedded spaces
            inside directory or filenames - an offense worthy of Gitmo
            :)

            My _vimrc contains:

            set runtimepath=$vimfiles,$vimruntime,$vimfiles\\after

            (I don't know where you got the idea that $vim was in there)
            where:

            let $vimfiles = $vim . '\vimfiles'

            is defined at the top of the file.

            --
            Best regards,
            Bill
          • A.J.Mechelynck
            ... I didn t; except you mentioned as a kind of justification that $HOME wasn t in it. Best regards, Tony.
            Message 5 of 10 , Jul 26 4:01 PM
            • 0 Attachment
              Bill McCarthy wrote:
              > On Wed 26-Jul-06 5:03pm -0600, A.J.Mechelynck wrote:
              >
              >> $HOME/vimfiles and $HOME/vimfiles/after should be in your 'rtp' (on
              >> Windows); the first place where Vim looks for your _vimrc is $HOME even
              >> though it is not in 'rtp'. (And BTW, $VIM should not be in your 'rtp'
              >> either; but $VIM/vimfiles and $VIM/vimfiles/after -- and $VIMRUNTIME
              >> which, on version 7.0, is $VIM/vim70 -- should.)
              >
              >>From :h starting
              >
              > Recommended place for your personal initializations:
              > MS-DOS and Win32 $HOME/_vimrc or $VIM/_vimrc
              >
              > I use the second choice.
              >
              > In an office environment I do use the $home directory for
              > all personalizations. But at home, I find it more
              > convenient to not do this - nor do I rely on automatic
              > assignment of $home (this can lead to using embedded spaces
              > inside directory or filenames - an offense worthy of Gitmo
              > :)
              >
              > My _vimrc contains:
              >
              > set runtimepath=$vimfiles,$vimruntime,$vimfiles\\after
              >
              > (I don't know where you got the idea that $vim was in there)
              > where:
              >
              > let $vimfiles = $vim . '\vimfiles'
              >
              > is defined at the top of the file.
              >

              I didn't; except you mentioned as a kind of "justification" that $HOME
              wasn't in it.


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