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

VIM - Detect Whether a Plugin is Active/Running/Open?

Expand Messages
  • Eduardo Lúcio Amorim Costa
    I would like to do some tricks with VIM and so I ask the help of you guys! It is possible to detect whether a plugin is active/running/open? You can close a
    Message 1 of 11 , Feb 12 3:30 PM
    • 0 Attachment
      I would like to do some tricks with VIM and so I ask the help of you guys!

      It is possible to detect whether a plugin is active/running/open?
      You can close a plugin by its name?
      You can close a plugin when it loses focus?
      The goal is to create keyboard shortcuts (conditional) to be configured in "vimrc" so I can easily switch between plugins!

      Plus!

      Is there any plugin that facilitates the activities mentioned?

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Gary Johnson
      ... I think you may need to learn a little more about plugins. See ... It may also help to read a few plugins by the better authors. Plugins are not opened
      Message 2 of 11 , Feb 12 4:21 PM
      • 0 Attachment
        On 2014-02-12, Eduardo Lúcio Amorim Costa wrote:
        > I would like to do some tricks with VIM and so I ask the help of you guys!
        >
        > It is possible to detect whether a plugin is active/running/open?
        > You can close a plugin by its name?
        > You can close a plugin when it loses focus?
        > The goal is to create keyboard shortcuts (conditional) to be
        > configured in "vimrc" so I can easily switch between plugins!

        I think you may need to learn a little more about plugins. See

        :help plugin
        :help write-plugin

        It may also help to read a few plugins by the better authors.

        Plugins are not "opened" or "closed". They are collections of ex
        commands that are sourced (or loaded) pretty much as though they
        were typed at the keyboard. They usually define a set of functions,
        commands, mappings and/or autocommands that are later executed by
        the user, either directly or in response to some event.

        Similarly, plugins do not "run" except as any Vim command or
        function "runs" when it is executed.

        There is normally no need to switch between plugins unless some
        mapping is used by more than one plugin. Such conflicts have to be
        handled case by case.

        Some plugins such as DrawIt can be put in an "on" or "off" state,
        which changes certain Vim options and how certain keys are
        interpreted, but such plugins are the exception.

        Otherwise, the only way to remove the functionality of a plugin is
        to remove some or all of its components. Most plugins do not
        provide a means to do this because there is usually no need. If a
        user doesn't want to use the features of a plugin, he either simply
        doesn't invoke them or he doesn't install the plugin in the first
        place.

        Now for the usual question at this point in the discussion: What
        problem are you trying to solve?

        Regards,
        Gary

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • James
        What you re probably looking for is a plugin manager. I know that with the Vizardry plugin manager, you can enable/disable plugins by name from inside vim as
        Message 3 of 11 , Feb 13 4:32 PM
        • 0 Attachment
          What you're probably looking for is a plugin manager.

          I know that with the "Vizardry" plugin manager, you can enable/disable plugins by name from inside vim as well as list which plugins you have enabled/disabled.

          The one caveat is that for Vizardry, and probably most other plugin managers as well, disabling a plugin doesn't take full effect until after you restart Vim for the reasons Gary mentioned. I've been considering adding the ability to hard refresh(dump all maps, autocmds, etc and reload them from the plugins/vimrc) to work around this if that's something people would find useful.

          -James


          On Wednesday, February 12, 2014 7:21:03 PM UTC-5, Gary Johnson wrote:
          > On 2014-02-12, Eduardo Lúcio Amorim Costa wrote:
          >
          > > I would like to do some tricks with VIM and so I ask the help of you guys!
          >
          > >
          >
          > > It is possible to detect whether a plugin is active/running/open?
          >
          > > You can close a plugin by its name?
          >
          > > You can close a plugin when it loses focus?
          >
          > > The goal is to create keyboard shortcuts (conditional) to be
          >
          > > configured in "vimrc" so I can easily switch between plugins!
          >
          >
          >
          > I think you may need to learn a little more about plugins. See
          >
          >
          >
          > :help plugin
          >
          > :help write-plugin
          >
          >
          >
          > It may also help to read a few plugins by the better authors.
          >
          >
          >
          > Plugins are not "opened" or "closed". They are collections of ex
          >
          > commands that are sourced (or loaded) pretty much as though they
          >
          > were typed at the keyboard. They usually define a set of functions,
          >
          > commands, mappings and/or autocommands that are later executed by
          >
          > the user, either directly or in response to some event.
          >
          >
          >
          > Similarly, plugins do not "run" except as any Vim command or
          >
          > function "runs" when it is executed.
          >
          >
          >
          > There is normally no need to switch between plugins unless some
          >
          > mapping is used by more than one plugin. Such conflicts have to be
          >
          > handled case by case.
          >
          >
          >
          > Some plugins such as DrawIt can be put in an "on" or "off" state,
          >
          > which changes certain Vim options and how certain keys are
          >
          > interpreted, but such plugins are the exception.
          >
          >
          >
          > Otherwise, the only way to remove the functionality of a plugin is
          >
          > to remove some or all of its components. Most plugins do not
          >
          > provide a means to do this because there is usually no need. If a
          >
          > user doesn't want to use the features of a plugin, he either simply
          >
          > doesn't invoke them or he doesn't install the plugin in the first
          >
          > place.
          >
          >
          >
          > Now for the usual question at this point in the discussion: What
          >
          > problem are you trying to solve?
          >
          >
          >
          > Regards,
          >
          > Gary

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Marc Weber
          ... Does it happen that you re the author? Would you mind stating what your goals are? Then I can document it an my wiki ..
          Message 4 of 11 , Feb 13 5:11 PM
          • 0 Attachment
            > James
            Does it happen that you're the author?

            Would you mind stating what your goals are?
            Then I can document it an my wiki ..
            http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
            (you can just add additional information yourself, see contributing or
            click on the edit link)

            If you want to continue this script consider joining
            https://bitbucket.org/vimcommunity/vim-pi

            We have quite a lot of discussions going on about how to move into the
            future.

            If you happen to use Win one day you may want to try http://vam.mawercer.de/.

            Marc Weber

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • James
            ... Yes, I wrote Vizardry. It s goals are: 1) To be simple and easy to use rather than featureful. 2) To focus more on dynamicly and quickly finding and trying
            Message 5 of 11 , Feb 13 6:34 PM
            • 0 Attachment
              > Marc Weber

              Yes, I wrote Vizardry. It's goals are:
              1) To be simple and easy to use rather than featureful.
              2) To focus more on dynamicly and quickly finding and trying out plugins on the fly, instead of storing a static list in the vimrc. (This is one reason I think it might fit what Eduardo is looking for)

              Vim-pi looks like it will be pretty useful, but probably outside the scope of Vizardry. Vizardry uses a github api search to find plugins, which allows for the simplicity of having github do all the heavy lifting while working very well for all my (and hopefully other people's) use cases.

              -James

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • lith
              ... I personally don t quite understand what you re aiming at. Could you please give some sort of example what you mean by closing a plugin or a plugin
              Message 6 of 11 , Feb 14 2:28 AM
              • 0 Attachment
                > You can close a plugin by its name?
                > You can close a plugin when it loses focus?
                > The goal is to create keyboard shortcuts (conditional) to be configured in "vimrc" so I can easily switch between plugins!

                I personally don't quite understand what you're aiming at. Could you please give some sort of example what you mean by "closing a plugin" or "a plugin losing focus"?

                Regards

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Marc Weber
                ... What for? Vim is featureful, not simple, you are happily using it by ignoring some features. ... Those are exactly the goals of VAM, too. (Providing useful
                Message 7 of 11 , Feb 14 4:55 AM
                • 0 Attachment
                  Excerpts from James's message of Fri Feb 14 02:34:13 +0000 2014:
                  > 1) To be simple and easy to use rather than featureful.
                  What for? Vim is featureful, not simple, you are happily using it by
                  ignoring some features.

                  > 2) To focus more on dynamicly and quickly finding and trying out
                  > plugins on the fly, instead of storing a static list in the vimrc.
                  Those are exactly the goals of VAM, too. (Providing useful features).

                  What is complicated about "storing static" lists?
                  Its fast to restart Vim and its the only clean way to have a
                  reproducable setup - thus you want it - because unloading plugins
                  doesn't make sense for many reasons (yes, I've tried !)

                  Otherwise both NeoBundle, VAM (and vundle in some way) support loading
                  at runtime.

                  :VAMActivate always
                  1) checks whether dir is there
                  2) if not, installs the package
                  3) activates it
                  (regardless when its called)

                  It is the most simple interface I've seen - and it already provides
                  completion. What else do you need ?
                  Except a search with more info - and we should collaborate on that
                  Vundle users want such, too - we all want it. Why have 10 solutions?

                  2 days ago I've reviewed all issues in Vundle - which also "wants to be
                  simple" - and I've found about 3 issuen telling the author about simple
                  bugs that vimfiles should be used instead of .vim - so I guess there are
                  additional important properties such as "being maintained" well - which is
                  why I'd like to collaborate with all parties to see whether we can join
                  to delegate sub tasks - so that we all have less work - and still can
                  make everyone happy.

                  > Vim-pi looks like it will be pretty useful, but probably outside the
                  > scope of Vizardry. Vizardry uses a github api search to find plugins,
                  > which allows for the simplicity of having github do all the heavy
                  > lifting while working very well for all my (and hopefully other
                  > people's) use cases.
                  And what if you want to one of drchips plugins? You'll not even know
                  they exist then. Maybe its what you want.

                  I think the community needs more than "a github search" - a lot of
                  people found the old Sander's snipmate - which never got updated - had
                  tons of forks - and people join irc having problems - I got tired of
                  telling them "fix is to use upstream at github/garbas"- which is why I
                  started vim-wiki.mawercer.de (to tell people about upstream solutions).

                  Let me try your search (one example is enough to illustrate my point):

                  :Scry snipmate

                  0: msanders/snipmate.vim <<<<<<<<<<<< OUTDATED !!!
                  (snipMate.vim aims to be a concise vim script that implements some of
                  TextMate's snippets features in Vim. )

                  1: honza/vim-snippets <<<<<<<<<<<< this will point to garbas/snipmate, so you might be lucky ..
                  (vim-snipmate default snippets (Previously snipmate-snippets))

                  [... 3 more matches below, they are unimportant ]

                  Upstream garbas/snipmate does not even appear.

                  :Scry commenting
                  does miss my plugin github.com/MarcWeber/vim-addon-commenting which I
                  consider to be the most simple yet somewhat featureful solution
                  (which is what you like: being simple)

                  Do you think those two samples is enough to point out that
                  a simple github search does eventually miss the jewels ?

                  Maybe thats what you want. Otherwise join vim-wiki.mawercer.de (You'll
                  get commit access if you want)

                  If you search for snipmate there you'll be pointed to:
                  http://vim-wiki.mawercer.de/wiki/topic/text-snippets-skeletons-templates.html

                  which should provide a nice overview (the more people join, the more
                  comprehensive it'll get)

                  Of course you can do whatever you want - its only my point of view (as
                  always)

                  Marc Weber

                  [3]:

                  2: robhudson/snipmate_for_django
                  (Django snippets for SnipMate, the excellent Vim plugin)

                  3: kaichen/vim-snipmate-ruby-snippets
                  (Some snippets of vim' plugin snipMate.vim.)

                  4: jamescarr/snipmate-nodejs
                  (Various snippets for developing node.js from vim)

                  5: evidens/vim-twig
                  (Twig syntax highlighting, snipMate, etc.)

                  6: theunraveler/Drupal-Snippets-for-Vim
                  (Provides a bunch of autocomplete snippets for Vim using snipMate.)

                  7: mklabs/vim-backbone
                  (Lightweight bag of Vim utilities for Backbone - snipmate snippets,
                  templates and omnicompletion)

                  8: bonsaiben/bootstrap-snippets
                  (Twitter Bootstrap snippets for vim-snipmate)

                  9: juhasz/drupal_sublime-snippets
                  (Drupal snippets for Sublime Editor, converted from Vim snipMate
                  drupal-snippets)

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Andrew Stewart
                  ... 9 times out of 10 I prefer simple and easy to use over featureful. Vim is packed full of features but that doesn t mean everything else has to be too.
                  Message 8 of 11 , Feb 14 5:11 AM
                  • 0 Attachment
                    On 14 Feb 2014, at 12:55, Marc Weber <marco-oweber@...> wrote:
                    > Excerpts from James's message of Fri Feb 14 02:34:13 +0000 2014:
                    >> 1) To be simple and easy to use rather than featureful.
                    > What for? Vim is featureful, not simple, you are happily using it by
                    > ignoring some features.


                    9 times out of 10 I prefer simple and easy to use over featureful. Vim is packed full of features but that doesn't mean everything else has to be too.

                    Everybody has their own preference for how few or how many features they want. That's why I believe efforts to get everybody to use one single wiki / plugin manager / whatever are unrealistic.

                    Personally I found all the plugin managers too heavy so I wrote one that barely does anything. It does what I want and that's enough for me :)

                    Yours,
                    Andrew Stewart

                    P.S. If you're curious: https://github.com/airblade/voom

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Benjamin Klein
                    ... Maybe this is just me, but although Vim itself certainly is packed full of features , I didn t find it complicated or hard to use when I was starting out
                    Message 9 of 11 , Feb 14 5:24 AM
                    • 0 Attachment
                      On Feb 14, 2014, at 7:11 AM, Andrew Stewart <boss@...> wrote:

                      > 9 times out of 10 I prefer simple and easy to use over featureful. Vim is packed full of features but that doesn't mean everything else has to be too.

                      Maybe this is just me, but although Vim itself certainly is "packed full of features", I didn't find it complicated or hard to use when I was starting out (after I learned a few basic commands). I'm using Vundle right now. I had to do very little set-up to get it to work, and then just list the plugins I want to use in my .vimrc.

                      My point is that I'm probably not even taking full advantage of what Vundle can do, and yet it's never been hard for me to use. I don't think featureful == hard to use.

                      > Everybody has their own preference for how few or how many features they want. That's why I believe efforts to get everybody to use one single wiki / plugin manager / whatever are unrealistic.

                      I think what really would make it hard to get everybody to use a single tool would be that there are several established ones now, and maybe most of their users would be uninterested in changing to something else. If, however, the developers of some of the popular or older (etc.) ones could join together in working on a single one, maybe their users would follow. (I would.) I don't think that just because we have different preferences for how many features we want, we need a different plugin manager (or whatever) for each Vim user.

                      Ben

                      --
                      b

                      Sent from my iPhone

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Marc Weber
                      ... In which way? .. VAM separates activation from installation. The pathogen like part is only about 700 loc (which still is much, I agree). Collaboration
                      Message 10 of 11 , Feb 14 6:04 AM
                      • 0 Attachment
                        Excerpts from Andrew Stewart's message of Fri Feb 14 13:11:56 +0000 2014:
                        > Personally I found all the plugin managers too heavy
                        In which way? .. VAM separates activation from installation. The
                        "pathogen" like part is only about 700 loc (which still is much, I
                        agree).

                        Collaboration doesn't mean all code must be contained in a plugin
                        (leading to code bloat).
                        Having a nice search (everybody could use) would be fun, too.

                        At the moment we have:

                        vam.mawercer.de
                        vim-scripts.org (having trouble with duplicate script names)
                        search at vim.sf.net

                        ...

                        > P.S. If you're curious: https://github.com/airblade/voom
                        :-) I'll add it to the wiki. Improvements I see:
                        --depth 1 cloning is faster (but failed on google accounts in the past).
                        And this thread was about 'trying out many solutions fast' :)

                        I like the "simple list of plugins" - and VAM / vim-pi recently
                        implemented a proposal which could be used to share the plugin list:
                        https://bitbucket.org/vimcommunity/vim-pi/issue/95

                        Because VAM turns names into dictionaries now, you could just do

                        'github:repo/name'
                        'github:repo2/name2'
                        { 'name': 'php-plugin', .. if you need more add options such as lazy load if ft is php }
                        { 'name': 'php-plugin', 'flavour':'latex-development' }

                        The main reason behind this switch is that I feel supporting parallel
                        installs can be done in Vim (like NeoBundle does) - but I feel a python
                        script or such would do a better job, because Vim was never written to
                        do such. Also you could try different install/management methods and use
                        what works best for you.

                        Marc Weber

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Marc Weber
                        ... Vundle has different design choices. Eg it doesn t tell you if a plugin you want is missing (unless you run BundleInstall) - Shougo fixed that by
                        Message 11 of 11 , Feb 14 6:59 AM
                        • 0 Attachment
                          Excerpts from Benjamin Klein's message of Fri Feb 14 13:24:52 +0000 2014:
                          > My point is that I'm probably not even taking full advantage of what Vundle can do, and yet it's never been hard for me to use. I don't think featureful == hard to use.
                          Vundle has different design choices. Eg it doesn't tell you if a plugin
                          you want is missing (unless you run BundleInstall) - Shougo "fixed" that
                          by introducing NeoBundleCheck - however using VAM everything is right by
                          design - if a plugin is missing the VAMActivate just checks it out.

                          Its a small difference, and I've filed a bug against Vundle (for this
                          reason) - to think about why it is the way it.

                          Vundle is fun - unless you happen to hit these issues:

                          same names at vim.sf.net cannot be used:
                          #183, #323, #173

                          The fact that there are 3 bug reports for one topic talks for itself
                          (sry).

                          > > Everybody has their own preference for how few or how many features they want. That's why I believe efforts to get everybody to use one single wiki / plugin manager / whatever are unrealistic.
                          I think what really would make it hard to get everybody to use a
                          > single tool would be that there are several established ones now, and
                          > maybe most of their users would be uninterested in changing to
                          > something else. If, however, the developers of some of the popular or
                          > older (etc.) ones could join together
                          That's what I'm trying. I even offered gmarik to continue vam's engine
                          under the name vundle .. his reaction was "you can help with vundle"
                          - and if I did i would turn it into VAM - which is why I cannot do it.

                          What I did is reviewing all bug reports for Vundle extending VAM so that
                          some of those issues (such as version lock) could be implemented easily
                          now. (only the git checkout .. commands are missing).

                          The main problem is not that something (eventually) went wrong, the main
                          problem is that its likely to happen again - beacuse we don't have a
                          single source of knowledge to lookup existing solutions (if people still
                          prefer to write their own stuff for arbitrary reasons I'm fine with it -
                          but then they can document why they do it !)

                          Current situation exists because vundle was started and Shougo "fixed"
                          Vundle by turning it into NeoBundle (without knowing about VAM).

                          I'm waiting for Shougo to tell me how much benefit parallel installation
                          really has - so that I understand whether I should push this feature,
                          too.

                          So I'm trying to collaborate on

                          - unique interface to declare plugins (having one command so that its
                          easier to switch - VAM already has a somewhat working vundle
                          emualtion, some details are missing but are trivial to fix)

                          - a plugin pool which can be searched (vam.mawercer.de is for Windows
                          users and to lookup sources), vim-scripts.org (suffering from mapping
                          differenct script ids but same title to the same keys )

                          - joined effort to cerate a website (vim.sf.net - and plugin search!)

                          - mark plugins as "depracated" if there are strong reasons. This still
                          should allow users to install them - but tell them that there might be
                          better alternatives (to fight against the problem what used to be good
                          doesn't neet to be the best solution tomorrrow - but stars and votings
                          will tell you something else)

                          vim-wiki is one attempt - and you probably alos have seen the other
                          thread that I'd like to move some wiki features to important pages on
                          vim.sf.net (because I cannot / don't want) to rewrite vim.sf.net for
                          many reasons.

                          > maybe their users would follow. (I would.)

                          > because we have different preferences for how many features we want,
                          > we need a different plugin manager (or whatever) for each Vim user.
                          Yes - but wouldn't it still be nice if all plugin managers would support

                          Script 'foo/bar'

                          syntax? At least tons of README's could be simplified to:

                          " Script explanation/syntax see http://wiki-url
                          " dependencies:
                          " Script 'dep1/baz'
                          " Script 'dep2/baz'
                          Script 'foo/bar'

                          and it would just work whatever manager you're using.
                          Discuss at: https://bitbucket.org/vimcommunity/vim-pi/issue

                          Reasons behind this proposal is that I get install patches like these:
                          https://github.com/honza/vim-snippets/pull/307
                          (Think about having 5 managers and 4 plugins and maybe some optional
                          dependencies or different dependencies like in the vim-snippets case
                          that would make a long page telling about how to install something)

                          Currently most plugin managers implement their own kind of "shell" dsl,
                          because writing quoted commands in Vim is hard (shellescape etc, see
                          vundle issues) - this one issue was reported / asked about 3 times (none
                          of those issues got closed)

                          So another thing to think about is what about moving what have achived
                          into vimruntime ? (Another story)

                          But new vimruntime's must be stable, because you cannot easily replace
                          them on many systems ..

                          (Just some thoughts)

                          Marc Weber

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        Your message has been successfully submitted and would be delivered to recipients shortly.