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

Re: [vimdev] customizing plugins

Expand Messages
  • Benji Fisher
    ... 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
    Message 1 of 10 , Sep 27, 2002
    • 0 Attachment
      On Friday, September 27, 2002, at 02:21 PM, Charles E. Campbell wrote:

      > Hello!
      >
      > The problem with customizing plugins is that some things
      > need to be done before loading the plugin and some afterwards.
      > Doing things inside the plugin itself causes havoc when
      > the plugin gets updated.
      >
      > Here are two ways to do things before the plugin loads:
      > [snip]
      > Here are two ways to do things after plugins load:
      > [snip]

      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 do not know what sort of havoc you have in mind. Can you give an
      example?

      It seems to me that, if done carefully, everything can be done
      inside the plugin. Part of the reason for this thread is to establish
      standards, so that it is easier to get it right. The plugin can

      * do whatever needs to be done first
      * read in the customization file
      * do more stuff
      * define VimEnter or other autocommands for stuff that has to be done
      later

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

      --Benji Fisher
    • 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 2 of 10 , Sep 27, 2002
      • 0 Attachment
        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 3 of 10 , Sep 27, 2002
        • 0 Attachment
          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 4 of 10 , Sep 27, 2002
          • 0 Attachment
            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 5 of 10 , Sep 27, 2002
            • 0 Attachment
              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.