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

Re: [vimdev] customizing plugins

Expand Messages
  • Charles E. Campbell
    ... I d assume you re anticipating a number of commented out option variable settings in ; if this file is part of the distributed tarball, then the
    Message 1 of 10 , Sep 27, 2002
      On Fri, Sep 27, 2002 at 02:43:17PM -0400, Benji Fisher wrote:
      > On Friday, September 27, 2002, at 02:21 PM, Charles E. Campbell wrote:
      > I guess you do not agree that having foo.vim and foo.vimrc in the
      > same directory is desirable; the solutions I snipped put the
      > customizations far from the plugin file.

      I'd assume you're anticipating a number of commented out option
      variable settings in <foo.vimrc>; if this file is part of the
      distributed tarball, then the process of expanding the tarball will wipe
      out user customizations.

      > I do not know what sort of havoc you have in mind. Can you give an
      > example?

      The problem here is that customizations in the file will be wiped
      out on the next update. Repeatedly doing this will be a nuisance
      and prone to the user not updating things correctly.

      > If foo.vimrc sets "plugin options", I do not think any of it has to be
      > done after :sourc'ing foo.vim .

      Winmanager is an example of where the plugin needs to be loaded before
      the WMToggle command is issued.

      Regards,
      Chip Campbell

      --
      Charles E Campbell, Jr, PhD _ __ __
      Goddard Space Flight Center / /_/\_\_/ /
      cec@... /_/ \/_//_/
      PGP public key: http://www.erols.com/astronaut/pgp.html
    • Bram Moolenaar
      ... [...] ... This sounds like a good idea to me. It s the best solution I know to the problem of carrying over settings from one version to another. Instead
      Message 2 of 10 , Sep 27, 2002
        Benji fisher wrote:

        > I think we need a good way to let users customize plugins. There are
        > several ways to do this, and I think it will be helpful if we can agree on a
        > standard.
        [...]
        > I have one suggestion; there may be better ideas. My plugin,
        > foo.vim, will search for a file foo.vimrc and :source it. For
        > non-standard plugins, this file can go in the same directory as
        > foo.vim itself. Then my plugin can look something like this:

        This sounds like a good idea to me. It's the best solution I know to
        the problem of carrying over settings from one version to another.

        Instead of requiring that the foo.vimrc file is in the same directory as
        the plugin itself, you could use ":runtime" to search the $VIMRUNTIME
        path. This does work for standard [ft]plugins. For optional plugins I
        suppose it's still easier to put the foo.vimrc file in the same
        directory as the foo.vim file. At least it won't get lost.

        --
        hundred-and-one symptoms of being an internet addict:
        73. You give your dog used motherboards instead of bones

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Benji Fisher
        ... I would not include in the tarball. I would recommend that the user generate it by copying some lines from to (new file)
        Message 3 of 10 , Sep 27, 2002
          On Friday, September 27, 2002, at 02:59 PM, Charles E. Campbell wrote:

          > On Fri, Sep 27, 2002 at 02:43:17PM -0400, Benji Fisher wrote:
          >> On Friday, September 27, 2002, at 02:21 PM, Charles E. Campbell wrote:
          >> I guess you do not agree that having foo.vim and foo.vimrc in the
          >> same directory is desirable; the solutions I snipped put the
          >> customizations far from the plugin file.
          >
          > I'd assume you're anticipating a number of commented out option
          > variable settings in <foo.vimrc>; if this file is part of the
          > distributed tarball, then the process of expanding the tarball will wipe
          > out user customizations.
          >
          >> I do not know what sort of havoc you have in mind. Can you give
          >> an
          >> example?
          >
          > The problem here is that customizations in the file will be wiped
          > out on the next update. Repeatedly doing this will be a nuisance
          > and prone to the user not updating things correctly.

          I would not include <foo.vimrc> in the tarball. I would recommend
          that the user generate it by copying some lines from <foo.vim> to (new
          file) <foo.vimrc> in the same directory. If the user wants to edit the
          file, I cannot stop him (or her); but maybe I should not mention that
          option explicitly. I could even be fancy: when <foo.vim> is :source'd,
          it could look for <foo.vimrc>; if not found, create it and set up an
          autocommand to call a function that prompts the user to customize it.

          Later versions will contain installation instructions that remind
          the user not to overwrite <foo.vimrc> and maybe even update it.

          >> If foo.vimrc sets "plugin options", I do not think any of it has to be
          >> done after :sourc'ing foo.vim .
          >
          > Winmanager is an example of where the plugin needs to be loaded before
          > the WMToggle command is issued.

          " in file WinManager.vimrc:
          " Uncomment this line if you want WinManager to open each time you use
          vim:
          " let g:WM_VimEnter = 1

          " in file WinManager.vim ...
          if exists("g:WM_VimEnter")
          au VimEnter * WMToggle
          endif

          The alternative is to instruct the user to define the autocommand
          in the vimrc file.

          --Benji Fisher
        • Benji Fisher
          ... I suppose even a non-standard plugin could be put in a system-wide $VIM/vimfiles/plugin/ directory, and using :runtime (or :runtime!) could be used to find
          Message 4 of 10 , Sep 27, 2002
            On Friday, September 27, 2002, at 03:24 PM, Bram Moolenaar wrote:

            >
            > Benji fisher wrote:
            >
            >> I think we need a good way to let users customize plugins. There
            >> are
            >> several ways to do this, and I think it will be helpful if we can
            >> agree on a
            >> standard.
            > [...]
            >> I have one suggestion; there may be better ideas. My plugin,
            >> foo.vim, will search for a file foo.vimrc and :source it. For
            >> non-standard plugins, this file can go in the same directory as
            >> foo.vim itself. Then my plugin can look something like this:
            >
            > This sounds like a good idea to me. It's the best solution I know to
            > the problem of carrying over settings from one version to another.
            >
            > Instead of requiring that the foo.vimrc file is in the same directory as
            > the plugin itself, you could use ":runtime" to search the $VIMRUNTIME
            > path. This does work for standard [ft]plugins. For optional plugins I
            > suppose it's still easier to put the foo.vimrc file in the same
            > directory as the foo.vim file. At least it won't get lost.

            I suppose even a non-standard plugin could be put in a system-wide
            $VIM/vimfiles/plugin/ directory, and using :runtime (or :runtime!) could
            be used to find files in $HOME/.vim/plugin/ as well as those in the
            system directory.

            Is .vimrc going to give trouble? (i.e., do we still have to
            support 8.3 file systems?) We could use .rc (as Zdenek Sekera
            suggested) or .vrc . (It looks as though *.rc is recognized as a "M$
            Resource file".)

            --Benji Fisher
          Your message has been successfully submitted and would be delivered to recipients shortly.