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

Re: vim60k: plugins not loaded

Expand Messages
  • Bram Moolenaar
    ... When you start Vim with the -u argument, it won t load the plugin files. I think it was already like this in the previous version. There is one change:
    Message 1 of 8 , Oct 30, 2000
    • 0 Attachment
      Zdenek Sekera wrote:

      > Vim60k:
      >
      > alias vi='vim6 -u .vimrc6'
      > $HOME=/usr/people/zs
      > $VIMRUNTIME=~/share/vim/vim60k

      When you start Vim with the "-u" argument, it won't load the plugin files.
      I think it was already like this in the previous version.

      There is one change: The plugins are only loaded when the +eval feature was
      compiled with. But I suppose you did compile with it, the plugins are
      useless otherwise.

      > Now, if I try
      >
      > :runtime plugin/*.vim
      > Searching for "plugin/*.vim" in
      > "/usr/people/zs/.vim,/usr/people/zs/share/vim/vi
      > mfiles,/usr/people/zs/share/vim/vim60k,/usr/people/zs/vim6"
      > sourcing "/usr/people/zs/share/vim/vim60k/plugin/netrw.vim"
      > Error detected while processing
      > /usr/people/zs/share/vim/vim60k/plugin/netrw.vim
      > :
      > line 67:
      > Command already exists: use ! to redefine
      > line 68:
      > Command already exists: use ! to redefine
      > finished sourcing /usr/people/zs/share/vim/vim60k/plugin/netrw.vim
      >
      >
      > So it at least finds the $VIMRUNTIME/plugin and gets netrw.vim from
      > there, but it still does nothing with my ~/vim6/plugin.

      You probably already defined the ":Nr" and ":Nw" commands in your own vimrc.
      The error in netrw.vim then stops further plugins to be loaded.

      Perhaps Vim should continue loading plugins, when one has caused an error?

      --
      For large projects, Team Leaders use sophisticated project management software
      to keep track of who's doing what. The software collects the lies and guesses
      of the project team and organizes them in to instantly outdated charts that
      are too boring to look at closely. This is called "planning".
      (Scott Adams - The Dilbert principle)

      /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
      \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
    • Zdenek Sekera
      ... Hoho! Yes, and I complained bitterly about it (how can one justify a different behaviour for otherwise identical vim and vim -u .vimrc ???), not
      Message 2 of 8 , Oct 31, 2000
      • 0 Attachment
        Bram Moolenaar wrote:
        >
        > Zdenek Sekera wrote:
        >
        > > Vim60k:
        > >
        > > alias vi='vim6 -u .vimrc6'
        > > $HOME=/usr/people/zs
        > > $VIMRUNTIME=~/share/vim/vim60k
        >
        > When you start Vim with the "-u" argument, it won't load the plugin files.
        > I think it was already like this in the previous version.
        >

        Hoho!
        Yes, and I complained bitterly about it (how can one justify a different
        behaviour for otherwise identical 'vim' and 'vim -u .vimrc' ???), not
        speaking about other problems it creates.

        And I thought you agreed and came up with a suggestion that looked
        really
        good (to me):


        From Bram Moolenaar <Bram@...>
        ...

        Date: Mon, 02 Oct 2000 14:05:55 +0200

        > Bram Moolenaar wrote:
        > >Zdenek Sekera wrote:
        > > However, I like the idea of "vim -u NONE" not loading a plugin. Then it's
        > > easier to start with an unmodified Vim session (e.g. to reproduce a bug).
        >
        > I agree. What about a new 'vim -u NOVIMRC' saying 'no .vimrc file' but
        > still loading 'system' plugins?

        Makes sense. Althought I would call it "NORC", since .exrc files are
        also
        skipped. Then the list becomes:

        <nothing> load vimrc load plugins
        -u NONE no vimrc no plugins
        -u NORC no vimrc load plugins
        --noplugins load vimrc no plugins

        --

        Unfortunately I haven't kept all my emails on this subject...

        For me it solved the problem. Have you just not implemented it yet and
        I missed it?

        vim -u something *must* load plugins (and behave in an identical way as
        when loading default .vimrc, unless *something* is one of above)
        otherwise
        plugin is unusable.

        ~
        > There is one change: The plugins are only loaded when the +eval feature was
        > compiled with. But I suppose you did compile with it, the plugins are
        > useless otherwise.
        >

        Yes, of course I did. Actually I think most of vim is unusable without
        +eval,
        it really becomes just a vi and vim is wonderfull because of its other
        features (in addition to vi compatibility) IMHO.

        [...]

        > You probably already defined the ":Nr" and ":Nw" commands in your own vimrc.

        Yes, I did but I don't see the relation to plugin loading, why is it
        related?

        > The error in netrw.vim then stops further plugins to be loaded.
        >
        > Perhaps Vim should continue loading plugins, when one has caused an error?

        Aha! Didn't know that. I would strongly vote for continuing loading
        plugins
        after an error. The *following* plugins after an error in one file
        shouldn't
        suffer from an error unrelated to them.

        ---Zdenek
      • Bram Moolenaar
        ... I thought we only talked about -u NONE so far. Apparently you expect plugins to be loaded when starting Vim with -u vimrc . Well, if you use this to
        Message 3 of 8 , Oct 31, 2000
        • 0 Attachment
          Zdenek Sekera wrote:

          > > When you start Vim with the "-u" argument, it won't load the plugin files.
          > > I think it was already like this in the previous version.
          >
          > Hoho!
          > Yes, and I complained bitterly about it (how can one justify a different
          > behaviour for otherwise identical 'vim' and 'vim -u .vimrc' ???), not
          > speaking about other problems it creates.

          I thought we only talked about "-u NONE" so far.

          Apparently you expect plugins to be loaded when starting Vim with "-u vimrc".
          Well, if you use this to skip just the .vimrc file, that would be logical.

          Are there disadvantages to still load the plugins when using "-u vimrc"? I
          can't think of one. You can still use "--noplugin" if you don't want it. Or
          reset 'loadplugins' in your vimrc file.

          > > You probably already defined the ":Nr" and ":Nw" commands in your own
          > > vimrc.
          >
          > Yes, I did but I don't see the relation to plugin loading, why is it
          > related?

          Because the netrw.vim plugin defines these commands. I think they should be
          called ":Nread" and ":Nwrite" to avoid this problem. Charles?

          > > The error in netrw.vim then stops further plugins to be loaded.
          > >
          > > Perhaps Vim should continue loading plugins, when one has caused an error?
          >
          > Aha! Didn't know that. I would strongly vote for continuing loading plugins
          > after an error. The *following* plugins after an error in one file shouldn't
          > suffer from an error unrelated to them.

          I'll put this in the todo list.

          --
          A salesperson says: translation:
          "backward compatible" Old technology
          "Premium" Overpriced
          "Can't keep it on the shelf" Unavailable
          "Stands alone" Piece of shit
          "Proprietary" Incompatible
          (Scott Adams - The Dilbert principle)

          /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
          \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
        • Zdenek Sekera
          ... -u NONE and friends were part of it. Here is how I see it: load plugins *always* unless told otherwise: - by -u NONE - by --noplugins I use different
          Message 4 of 8 , Oct 31, 2000
          • 0 Attachment
            Bram Moolenaar wrote:
            >
            > Zdenek Sekera wrote:
            >
            > > > When you start Vim with the "-u" argument, it won't load the plugin files.
            > > > I think it was already like this in the previous version.
            > >
            > > Hoho!
            > > Yes, and I complained bitterly about it (how can one justify a different
            > > behaviour for otherwise identical 'vim' and 'vim -u .vimrc' ???), not
            > > speaking about other problems it creates.
            >
            > I thought we only talked about "-u NONE" so far.
            >
            > Apparently you expect plugins to be loaded when starting Vim with "-u vimrc".
            > Well, if you use this to skip just the .vimrc file, that would be logical.
            >

            -u NONE and friends were part of it.

            Here is how I see it:
            load plugins *always* unless told otherwise:
            - by -u NONE
            - by --noplugins

            I use different .vimrc for different projects, so if '-u myvimrc'
            doesn't
            load plugins, that feature is useless for me.

            And besides, I really can't see why would we want 'vim' and 'vim -u
            ~/.vimrc' behave
            differently. That must be confusing to users.

            > Are there disadvantages to still load the plugins when using "-u vimrc"? I
            > can't think of one. You can still use "--noplugin" if you don't want it. Or
            > reset 'loadplugins' in your vimrc file.
            >

            I don't think there is any disadvantage in loading plugins for -u, just
            on
            the contrary, it's a neccessity if other features (above) to prevent
            loading
            it when wanted/needed/appropriate exist.

            > > > You probably already defined the ":Nr" and ":Nw" commands in your own
            > > > vimrc.
            > >
            > > Yes, I did but I don't see the relation to plugin loading, why is it
            > > related?
            >
            > Because the netrw.vim plugin defines these commands. I think they should be
            > called ":Nread" and ":Nwrite" to avoid this problem. Charles?
            >

            Hmmmm, maybe it's a good suggestion, but I can also take them away
            knowing
            they are defined in the file....


            > > Aha! Didn't know that. I would strongly vote for continuing loading plugins
            > > after an error. The *following* plugins after an error in one file shouldn't
            > > suffer from an error unrelated to them.
            >
            > I'll put this in the todo list.

            Good.

            ---Zdenek
          • Dr. Charles E. Campbell
            ... Hello! By analogy to :r and :w, I chose :Nr and :Nw. However, especially since vim 6.0 is going to make most transfers transparently (ie. the user will be
            Message 5 of 8 , Oct 31, 2000
            • 0 Attachment
              Thus saith Bram Moolenaar:
              > Because the netrw.vim plugin defines these commands. I think they should be
              > called ":Nread" and ":Nwrite" to avoid this problem. Charles?

              Hello!

              By analogy to :r and :w, I chose :Nr and :Nw. However, especially since
              vim 6.0 is going to make most transfers transparently (ie. the user will
              be less likely to type :Nread and :Nwrite) I don't see any problem
              changing that. For compatability reasons, I could probably define
              both :Nread and :Nr, :Nwrite and :Nw, and any conflicts which overrode
              :Nr/:Nw wouldn't prevent access to the functionality.

              Whatcha think?
              Chip Campbell

              --
              Charles E Campbell, Jr, PhD _ __ __
              Goddard Space Flight Center / /_/\_\_/ /
              cec@... /_/ \/_//_/
              PGP public key: http://www.erols.com/astronaut/pgp.html/
            • Zdenek Sekera
              ... Sounds simple and good, why not?
              Message 6 of 8 , Oct 31, 2000
              • 0 Attachment
                "Dr. Charles E. Campbell" wrote:
                >
                > Thus saith Bram Moolenaar:
                > > Because the netrw.vim plugin defines these commands. I think they should be
                > > called ":Nread" and ":Nwrite" to avoid this problem. Charles?
                >
                > Hello!
                >
                > By analogy to :r and :w, I chose :Nr and :Nw. However, especially since
                > vim 6.0 is going to make most transfers transparently (ie. the user will
                > be less likely to type :Nread and :Nwrite) I don't see any problem
                > changing that. For compatability reasons, I could probably define
                > both :Nread and :Nr, :Nwrite and :Nw, and any conflicts which overrode
                > :Nr/:Nw wouldn't prevent access to the functionality.
                >

                Sounds simple and good, why not?

                ---Zdenek
              • Bram Moolenaar
                ... If you define the :Nread and :Nwrite commands, the user can type :Nr and :Nw if there are no other commands that cause ambiguety. No need to define both
                Message 7 of 8 , Oct 31, 2000
                • 0 Attachment
                  Charles Campbell wrote:

                  > By analogy to :r and :w, I chose :Nr and :Nw.

                  :r is short for :read, :w is short for :write.

                  > However, especially since vim 6.0 is going to make most transfers
                  > transparently (ie. the user will be less likely to type :Nread and :Nwrite)
                  > I don't see any problem changing that. For compatability reasons, I could
                  > probably define both :Nread and :Nr, :Nwrite and :Nw, and any conflicts
                  > which overrode :Nr/:Nw wouldn't prevent access to the functionality.

                  If you define the :Nread and :Nwrite commands, the user can type :Nr and :Nw
                  if there are no other commands that cause ambiguety. No need to define both
                  :Nr and :Nread. Won't even be possible.

                  --
                  Engineers understand that their appearance only bothers other people and
                  therefore it is not worth optimizing.
                  (Scott Adams - The Dilbert principle)

                  /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                  \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                Your message has been successfully submitted and would be delivered to recipients shortly.