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

Re: pythonx patch - :pyx command

Expand Messages
  • Andy Kittner
    ... I 100% agree with ZyX on this one. Yes plugins may define reusable interfaces, but there s no reason to pollute the global namespace with them ...
    Message 1 of 25 , Jun 1, 2013
    • 0 Attachment
      On Sat, Jun 01, 2013 at 05:44:17AM +0200, Marc Weber wrote:

      >j And third, you must not use the same code as :pyfile. It is already
      >> bad that somebody may think that creating large file sourced using
      >> :pyfile is a good idea: it is never a good idea because file executed
      >> via :pyfile is executed as a part of __main__ package polluting global
      >> scope.
      >Maybe you want it. Its what plugins do: define interfaces for others?
      I 100% agree with ZyX on this one.
      Yes plugins may define reusable interfaces, but there's no reason to
      pollute the global namespace with them

      >
      >I have never used :pyfile and would suggest anybody against it.
      >> With autoloading *.py files using the same code you run into the same
      >> issue.
      >So, what would you do instead?
      >plugins/*.vim files also pollute global space, it depends on the user
      >how he/she uses it.
      Essentially what we want is a way to automatically import some module
      and call a boostrap method on it so it can set up mappings,
      autocommands, etc. Nothing more, nothing less.

      Python is not vim, just because vim plugins all share one namespace it
      doesn't make sense for python plugins to behave the same. In fact this
      would go against the python zen:
      "Namespaces are one honking great idea -- let's do more of those!"


      >I don't think this forum is the right place to write up about this.
      >I think the :h if_pyth.txt is - or an official wiki.
      Well once a solution is implemented we should document how it works and
      what the "best practices" are in if_pyth.txt, but hashing out how a
      solution should look like should happen here on the mailing list.

      >
      >> Even with the latter fixed I would only put some necessary initialization into such files thus
      >> b) I would merge this at the same time with merging `sys.path`
      >> addition once it is implemented.
      >I've thought about this again and I think plugins can do this themselves
      >as needed, eg using __FILE__ constant easily.
      >
      >ZyX: Can you explain once gain how you'd prevent plugins from polluting
      >global scope while letting plugins author to define their own stuff?
      >
      >Should we run such code:
      >
      > http://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path
      >
      > import imp
      > imp.load_source('module.name', '/path/to/file.py')
      >
      >This would mean that contents in path/to/file.py would be local to
      >module module.name
      >
      >But then we have to think about how to allow sharing - eg privde a
      >module vim_shared whichs sole purpose is to share a global dictionary?
      Yuk! No! If I want to reuse another module I import it, there is no need
      to stuff everything into one module which would also force everyone to
      use DamnLongPrefixes as a poor man's namespace...

      A clean solutions establishes a connection between vims runtimepath and
      the pythons sys.path (the import hook proposed in the other thread seems
      like a reasonable idea for this) and then defines a way to automatically
      run a bootstrapping function.
      The latter could even be a file in plugins/, maybe using .vimpy or some
      such as file extension to avoid backwards compatibility problems.

      Regards,
      Andy
      --
      The Unknown surrounds us at any given moment. That is where we seek knowledge.

      -- MOTHER SUPERIOR RAQUELLA BERTO-ANIRUL: Oratory Against Fear
    • ZyX ZyX
      ... It is vim coding style You may use what you want in your projects, but when writing patches for existing one do use existing style. ... I read this as let
      Message 2 of 25 , Jun 1, 2013
      • 0 Attachment


        On Jun 1, 2013 7:43 AM, "Marc Weber" <marco-oweber@...> wrote:
        >
        > ZyX: Usually you're rigth with what you're saying.
        > So please help find the best forum to place your "style guides" about
        > "how to write unobstrusive perfect python based vim plugins".
        >
        > You all know that I've introduced this wiki:
        > http://vim-wiki.mawercer.de/
        >
        > I think such (and making such official) would be the best way to tell
        > users how to write plugins - it should be open to everyone and it should
        > be available offline.
        >
        > Whether I use tabs or spaces is not visible to users.
        > Making python scripts interruptable is more important to me.

        It is vim coding style You may use what you want in your projects, but when writing patches for existing one do use existing style.

        > > AFAIK that was discussed. Do use pyplugin/ and set this on by default.
        > > In the current state I will never turn this option on and will suggest
        > > everybody turn it off immediately I see it. It is not the user who
        > > chooses whether this option can be turned on, but plugin writers.
        > There is no reason to introduce yet another directory people have to
        > remember. Keep things simple. Plugins will adopt soon.
        >
        > I read the rule as "everything you put into plugin/* will be sourced"
        > Its simple and understandable. If plugins don't follow this rule, they
        > can be changed easily.
        > Its an implementation detail we can discuss.

        I read this as "let us introduce problems without reason". Being disabled by default this option will force plugin writers still have plugin/*.vim file.

        I would really prefer pyload() described earlier with pip as a plugin manager.

        > j And third, you must not use the same code as :pyfile. It is already
        > > bad that somebody may think that creating large file sourced using
        > > :pyfile is a good idea: it is never a good idea because file executed
        > > via :pyfile is executed as a part of __main__ package polluting global
        > > scope.
        > Maybe you want it. Its what plugins do: define interfaces for others?

        No. When python developer wants to define interfaces he uses importable modules. In the current state it only rises probability of conflict.

        > I have never used :pyfile and would suggest anybody against it.
        > > With autoloading *.py files using the same code you run into the same
        > > issue.
        > So, what would you do instead?
        > plugins/*.vim files also pollute global space, it depends on the user
        > how he/she uses it.

        plugin/*.vim have s:. Python has nothing like this.

        > I don't think this forum is the right place to write up about this.
        > I think the :h if_pyth.txt is  - or an official wiki.
        >
        > > Even with the latter fixed I would only put some necessary initialization into such files thus
        > > b) I would merge this at the same time with merging `sys.path`
        > > addition once it is implemented.
        > I've thought about this again and I think plugins can do this themselves
        > as needed, eg using __FILE__ constant easily.
        >
        > ZyX: Can you explain once gain how you'd prevent plugins from polluting
        > global scope while letting plugins author to define their own stuff?

        "Polluting" here means that you make *all* auxiliary stuff in global scope. Not polluting means that you push nothing into __main__ and only UI parts into vim global scope.

        In pyplugin/* you should do two things: import modules placed in python/* and use imported stuff to define UI: like this:

        from foo import mapfuncs
        import vim

        for (mapname, mapmode, defaultlhs, mapdescr) in mapfuncs:
            lhs=vim.vars.get('foo_map_' + mapname, defaultlhs)
            map=vim.Mapping(**mapdescr)
            vim.mappings[mapmode][lhs]=map

        # similar cycle for commands, autocommands and menus

        > Should we run such code:
        >
        >   http://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path
        >
        >   import imp
        >   imp.load_source('module.name', '/path/to/file.py')
        >
        > This would mean that contents in path/to/file.py would be local to
        > module module.name
        >
        > But then we have to think about how to allow sharing - eg privde a
        > module vim_shared whichs sole purpose is to share a global dictionary?

        You do share things in python by creating importable modules. Files in pyplugin/ must not contain anything to share. E.g. define this dictionary in python/foo.py and use it in other plugins by doing "from foo import bar_dict". Don't pull bad habits from VimL to python, *python developers already created everything you need*.

        > 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.
        >
        >

        --
        --
        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
        @ZyX: I totally agree on plugin/ being a bad choice. And I also agree that the patch is not perfect. I had to get it out due to Brams deadline (Friday) -
        Message 3 of 25 , Jun 1, 2013
        • 0 Attachment
          @ZyX: I totally agree on plugin/ being a bad choice. And I also agree
          that the patch is not perfect. I had to get it out due to Brams deadline
          (Friday) - because otherwise much worse things could have happened -
          people starting to use if py2 then .. else .. code which you cannot get
          rid of.

          I also feel that we're not ready to know what is the perfect solution.

          I also think that the mailinglist is a good place to discuss, but not to
          keep track of the results of a discussion.

          So what about moving it to a wiki?

          I've written down the topics I'm interested in:
          http://vim-wiki.mawercer.de/wiki/vim74/improving-python-support-drafts.html

          And I'd like to integrate the drafts you've written earlier. Can you
          tell me which is the most up to date information I should be working
          with?

          Next thing which is important to me is being able to use ctrl-c to abort
          a python script.

          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.
        • ZyX
          ... I have posted a link in that RFC thread to a gist with a draft: https://gist.github.com/ZyX-I/5561409. ... About solution with imp.load_source: it is not
          Message 4 of 25 , Jun 2, 2013
          • 0 Attachment
            воскресенье, 2 июня 2013 г., 2:51:35 UTC+4 пользователь MarcWeber написал:
            > @ZyX: I totally agree on plugin/ being a bad choice. And I also agree
            > that the patch is not perfect. I had to get it out due to Brams deadline
            > (Friday) - because otherwise much worse things could have happened -
            > people starting to use if py2 then .. else .. code which you cannot get
            > rid of.
            >
            > I also feel that we're not ready to know what is the perfect solution.
            >
            > I also think that the mailinglist is a good place to discuss, but not to
            > keep track of the results of a discussion.
            >
            > So what about moving it to a wiki?
            >
            > I've written down the topics I'm interested in:
            > http://vim-wiki.mawercer.de/wiki/vim74/improving-python-support-drafts.html
            >
            > And I'd like to integrate the drafts you've written earlier. Can you
            > tell me which is the most up to date information I should be working
            > with?

            I have posted a link in that RFC thread to a gist with a draft: https://gist.github.com/ZyX-I/5561409.

            >
            > Next thing which is important to me is being able to use ctrl-c to abort
            > a python script.
            >
            > Marc Weber


            ---

            About solution with imp.load_source: it is not needed as you have

            execfile(filename, {}, {})

            . Yes, this won't keep the scope, but you don't need to: all shared interfaces are to be defined in modules and if you post a closure somewhere outer scope is also saved thus there is no problem.

            You must not use imp.load_source because you don't need this module shared. It is completely fine in python to enforce some one best practice like it does with indentation, it is not perl with its TIMTOWTDI principle. And taking only one last path component when generating module name is far from the best idea.

            > try:
            > from vim.plugin.file_name import

            should not be there;

            > import __main__
            > if hasattr(__main__, 'user_setting'):

            should either be replaced with `vim.vars` querying or with specific `vim.config` object similar to `c = get_config()` object found in IPython (I would really prefer the latter).

            Also note that with pip suggestion the only thing pyplugin should do is

            from foo import __vim_init__
            __vim_init__()

            > I feel bad about forcing support for any solution. It should be optional always. The same way we could provide ways to install exuberant-ctags for all oses. Also using pip to check for packages is much more time consuming (untested) than vam's test "does directory exist" to find out wether a plugin is there?

            You have missed my message. **Pip is run if import fails.** You don't use pip to check for existence of the package. It does not matter how you installed the package since it can be imported, but using pip is the easiest way to install the plugin.

            If not pip what do you suggest. We must have built-in support for dependencies. VAM is not able to install python package (and is not a tiny bit standard solution). No other uniform solutions exist. Pip is the standard way of distributing files in python, thus having built-in support for pip is good (though with settings 'pythoninstallprg' and 'python3installprg' as for different python versions you have different pip executables and one may also want to replace default `pip install` with `easy_install`).

            Pip is also responsible for doing all necessary initialization (i.e. compilation of the sources) at installation or update.

            > vim.ensurep_python_library_exists('pip', 'foo')

            It is expected that package is installed by the time module is imported. It acts directly against "explicit is better the implicit" principle: imported module is not expected to do anything except for defining functions, classes and variables. It should not install something, or define options or create vim mappings/commands. At maximum it should initialize globals used e.g. for cache. Job is done by using defined functions or classes.

            > Also pip is the successor of easy_install. So even in the python community things may change faster than Vim which could make it hard /impossible for Vim maintainers to maintain such, too.

            This one is covered by 'python*installprg' settings. Though I thought about them only due to having four different pip executables for each of four python versions installed system-wide.

            Note that you can replace `pip install` prefix with `easy_install` almost always. Thus switching between them is changing one setting (and easy_install still works BTW). The suggested function does nothing more then calling `system(&pythoninstallprg . ' ' . (a:0 ? a:1 : shellescape(matchstr(a:module_name, '^[^.]\+'))))` in case of ImportError and retrying import thus changing to other installer is easy.

            --
            --
            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
            ... Would you pass a permanent individual global state dictionary like this? if not foo.py in module_globals: module_globals[ foo.py ] = {}
            Message 5 of 25 , Jun 2, 2013
            • 0 Attachment
              Excerpts from ZyX's message of Sun Jun 02 12:58:10 +0200 2013:
              > execfile(filename, {}, {})
              Would you pass a permanent individual global state dictionary like this?

              if not "foo.py" in module_globals:
              module_globals["foo.py"] = {}
              execfile("foo.py", module_globals["foo.py"], {})

              Then a plugin would have a chance to notice when it gets reloaded /
              updated. That could be nice when developing a plugin.

              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.
            • ZyX ZyX
              ... What for? Holding state this way will act against the reloading feature (you will have to clear dictionary in place of using a new instance). If one needs
              Message 6 of 25 , Jun 3, 2013
              • 0 Attachment


                On Jun 3, 2013 9:55 AM, "Marc Weber" <marco-oweber@...> wrote:
                >
                > Excerpts from ZyX's message of Sun Jun 02 12:58:10 +0200 2013:
                > >     execfile(filename, {}, {})
                > Would you pass a permanent individual global state dictionary like this?
                >
                >   if not "foo.py" in module_globals:
                >     module_globals["foo.py"] = {}
                >   execfile("foo.py", module_globals["foo.py"], {})
                >
                > Then a plugin would have a chance to notice when it gets reloaded /
                > updated. That could be nice when developing a plugin.

                What for? Holding state this way will act against the reloading feature (you will have to clear dictionary in place of using a new instance). If one needs to hold state there are python modules. Remember: files in pyplugin/ should contain nearly no useful code, everything is to be put into modules. I am very unsure they are needed at all: loadpyplugin(module[, install_arg]) is much more useful. Custom loaders in plugin/*.vim as a fallback can at least show the error, same for loadpyplugin() in case of absent python. What do you get with pyplugin/ without +python with python-only plugins? I guess, silence.

                > 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.
                >
                >

                --
                --
                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
                ... Stupid simple plugins which want to have minimal state such as incermental counter ? I don t know yet. You re right, you could create a new module and
                Message 7 of 25 , Jun 3, 2013
                • 0 Attachment
                  Excerpts from ZyX ZyX's message of Mon Jun 03 13:28:10 +0200 2013:
                  > What for?
                  Stupid simple plugins which want to have minimal state such as
                  "incermental counter" ?

                  I don't know yet. You're right, you could create a new module and
                  import that just to keep state.

                  Anyway. Current interface is:

                  :py
                  :pydo
                  :pyfile
                  pyeval()

                  They all pollute global state, right?

                  So do we fix anything by introducing a new sane way for modules only?

                  What about:

                  let s:py_scope = 'my_plugin'

                  and from then one use exec(file/string) to run python code having that
                  scope?

                  s:py_scope could be initailized with the file name.

                  Then it would be you being able to use the same scope in all plugin/
                  autoload/* .vim files and everything would be saner ?

                  Scripts can be fixed in a backward compatible way, because s:py_scope is
                  a NOP in current Vim.

                  of course we could introduce a new set of commands/functions, too.

                  Being 100% backward compatible would require duplicating all
                  commands/functions/..

                  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
                  I still vote for the module solution, because you can import it into global namespace for debugging and testing. While writing plugins being able to ... is
                  Message 8 of 25 , Jun 3, 2013
                  • 0 Attachment
                    I still vote for the module solution, because you can import it into global
                    namespace for debugging and testing.

                    While writing plugins being able to

                    :py import my-module
                    :py my-module.do_thing(foo)

                    is important to me.

                    Using execfile('file',{},{})

                    access to the namespace is lost which would force me to move almost all
                    code into a module. So why not use a module in the first place?

                    About "being vergin". Could we just proivde a clean() function which
                    cleans a module namespace?

                    for x in globals():
                    delete x

                    People who want could use that then.

                    When wirting plugins I never bothered about cleaning any environment.
                    There are very rare cases when I have to - and then I restart Vim.

                    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.
                  • ZyX ZyX
                    ... ?! How my proposal is against this? When you create a python function that uses some variable from the outer scope this scope is saved. This works for
                    Message 9 of 25 , Jun 3, 2013
                    • 0 Attachment


                      On Jun 4, 2013 12:38 AM, "Marc Weber" <marco-oweber@...> wrote:
                      >
                      > Excerpts from ZyX ZyX's message of Mon Jun 03 13:28:10 +0200 2013:
                      > > What for?
                      > Stupid simple plugins which want to have minimal state such as
                      > "incermental counter" ?

                      ?! How my proposal is against this? When you create a python function that uses some variable from the outer scope this scope is saved. This works for execfile as well.

                      You don't need globals for such a state at all, you only need persistent globals if file is supposed to be sourced twice. Thus note about reloading by resourcing may be valid, note about incremental counter definitely is not.

                      > I don't know yet. You're right, you could create a new module and
                      > import that just to keep state.
                      >
                      > Anyway. Current interface is:
                      >
                      >   :py
                      >   :pydo
                      >   :pyfile
                      >    pyeval()
                      >
                      > They all pollute global state, right?
                      >
                      > So do we fix anything by introducing a new sane way for modules only?
                      >
                      > What about:
                      >
                      > let s:py_scope = 'my_plugin'
                      >
                      > and from then one use exec(file/string) to run python code having that
                      > scope?
                      >
                      > s:py_scope could be initailized with the file name.
                      >
                      > Then it would be you being able to use the same scope in all plugin/
                      > autoload/* .vim files and everything would be saner ?
                      >
                      > Scripts can be fixed in a backward compatible way, because s:py_scope is
                      > a NOP in current Vim.
                      >
                      > of course we could introduce a new set of commands/functions, too.
                      >
                      > Being 100% backward compatible would require duplicating all
                      > commands/functions/..
                      >
                      > 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.
                      >
                      >

                      --
                      --
                      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.
                       
                       
                    • ZyX ZyX
                      ... global ... Is not it what I am talking when writing about loadpyplugin()? Modules are not expected to be sourced automatically. Also nothing can prevent
                      Message 10 of 25 , Jun 3, 2013
                      • 0 Attachment


                        On Jun 4, 2013 12:54 AM, "Marc Weber" <marco-oweber@...> wrote:
                        >
                        > I still vote for the module solution, because you can import it into global
                        > namespace for debugging and testing.
                        >
                        > While writing plugins being able to
                        >
                        >   :py import my-module
                        >   :py my-module.do_thing(foo)
                        >
                        > is important to me.
                        >
                        >   Using execfile('file',{},{})
                        >
                        > access to the namespace is lost which would force me to move almost all
                        > code into a module. So why not use a module in the first place?

                        Is not it what I am talking when writing about loadpyplugin()? Modules are not expected to be sourced automatically. Also nothing can prevent you to record reference to globals somewhere.

                        The discussion has now gone into the direction when I will be against automatic sourcing of anything related to python. Your proposal does not error out without python (or it will be too intrusive in case sourcing python files is optional in some particular plugin), must not contain anything to be shared (because modules are not expected to be sourced without request and non-modules are not expected to contain anything to share) and putting anything meaningful there is against loadpyplugin() function meaning that it reduces to two lines: import and calling setup function.

                        > About "being vergin". Could we just proivde a clean() function which
                        > cleans a module namespace?
                        >
                        >   for x in globals():
                        >     delete x
                        >
                        > People who want could use that then.

                        I still do not see a single reason to keep globals.

                        >
                        > When wirting plugins I never bothered about cleaning any environment.
                        > There are very rare cases when I have to - and then I restart Vim.
                        >
                        > 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.
                        >
                        >

                        --
                        --
                        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
                        ... Wow.. peace. I don t want to be offensive. And its hard to follow this argument. this direction is not very descriptive. My goals: - make python (or any
                        Message 11 of 25 , Jun 3, 2013
                        • 0 Attachment
                          Excerpts from ZyX ZyX's message of Mon Jun 03 23:11:58 +0200 2013:
                          > The discussion has now gone into the direction when I will be against
                          > automatic sourcing of anything related to python.
                          Wow.. peace. I don't want to be offensive. And its hard to follow this
                          argument. "this direction" is not very descriptive.

                          My goals:
                          - make python (or any other scripting language) be as powerful as VimL
                          is. Thus if we extend python, try to use an interface which can be
                          extended to also include ruby, perl, ..
                          - keep simple things simple
                          - allow complicated things

                          If you think differently, then put your ideas / thoughts on your draft page
                          https://gist.github.com/ZyX-I/5561409 so that I can take time, read it
                          up, and think about it.

                          The idea is to:
                          1) gather what I/you/ others want
                          2) find all ways which could help getting there
                          3) list pro/cons
                          4) decide on a solution and start implementing the most valuable
                          features first.

                          I'm not sure in which phase we are. pythonx clearly showed that
                          we may be stuck at 1).

                          Improving python support is not the most simple thing, and we should try
                          hard to get it right for everybody who is interested in it.
                          Ensuring this requires us to talk about what we want.

                          What I've learned by your input (thanks!):
                          - I can import/access the global namespace called __main__ always
                          - It is good and easily possible to hide plugin initialization code from
                          each other

                          I've updated my file:
                          http://vim-wiki.mawercer.de/wiki/vim74/improving-python-support-drafts.html

                          Please pay attention to the comparing-execfile-vs-load_source link.

                          Summary: load_source puts variables and functions in both locals()
                          and globals() whereas execfile puts assigments into globals() and
                          functions into locals()

                          Does this make a difference matter? I've not been aware of that
                          difference.

                          If you have arguments for one or the other solution then just edit that
                          wiki file.

                          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.
                        • ZyX ZyX
                          ... I am no longer seeing why automatic sourcing of any python file from any directory should exist in case loadpyplugin() is implemented. ... page ... You
                          Message 12 of 25 , Jun 3, 2013
                          • 0 Attachment


                            On Jun 4, 2013 3:26 AM, "Marc Weber" <marco-oweber@...> wrote:
                            >
                            > Excerpts from ZyX ZyX's message of Mon Jun 03 23:11:58 +0200 2013:
                            > > The discussion has now gone into the direction when I will be against
                            > > automatic sourcing of anything related to python.
                            > Wow.. peace. I don't want to be offensive. And its hard to follow this
                            > argument. "this direction" is not very descriptive.

                            I am no longer seeing why automatic sourcing of any python file from any directory should exist in case loadpyplugin() is implemented.

                            > My goals:
                            >   - make python (or any other scripting language) be as powerful as VimL
                            >     is. Thus if we extend python, try to use an interface which can be
                            >     extended to also include ruby, perl, ..
                            >   - keep simple things simple
                            >   - allow complicated things
                            >
                            > If you think differently, then put your ideas / thoughts on your draft page
                            > https://gist.github.com/ZyX-I/5561409 so that I can take time, read it
                            > up, and think about it.
                            >
                            > The idea is to:
                            > 1) gather what I/you/ others want
                            > 2) find all ways which could help getting there
                            > 3) list pro/cons
                            > 4) decide on a solution and start implementing the most valuable
                            >   features first.
                            >
                            > I'm not sure in which phase we are. pythonx clearly showed that
                            > we may be stuck at 1).

                            You should have separated code. Code with pythonx commands and functions did not cause discussion, automatic loading did.

                            > Improving python support is not the most simple thing, and we should try
                            > hard to get it right for everybody who is interested in it.
                            > Ensuring this requires us to talk about what we want.
                            >
                            > What I've learned by your input (thanks!):
                            >   - I can import/access the global namespace called __main__ always
                            >   - It is good and easily possible to hide plugin initialization code from
                            >     each other
                            >
                            > I've updated my file:
                            > http://vim-wiki.mawercer.de/wiki/vim74/improving-python-support-drafts.html
                            >
                            > Please pay attention to the comparing-execfile-vs-load_source link.
                            >
                            > Summary: load_source puts variables and functions in both locals()
                            > and globals() whereas execfile puts assigments into globals() and
                            > functions into locals()

                            There are no locals in case using load_source. It does not put things into both, there just is only one dictionary. If I wrote the implementation though it will also show the same: why take care about two dictionaries when you can leave with one? In python code writing execfile(, {}, {}) is faster then saving dict somewhere thus I used this in illustration, but in C it would be the opposite. In any case with proposed contents of file it is irrelevant.

                            > Does this make a difference matter? I've not been aware of that
                            > difference.
                            >
                            > If you have arguments for one or the other solution then just edit that
                            > wiki file.
                            >
                            > 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.
                            >
                            >

                            --
                            --
                            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
                            ... It would be nice if you could include your idea about that function in your gist: https://gist.github.com/ZyX-I/5561409 I m interested in the following
                            Message 13 of 25 , Jun 3, 2013
                            • 0 Attachment
                              Excerpts from ZyX ZyX's message of Tue Jun 04 05:55:18 +0200 2013:
                              > I am no longer seeing why automatic sourcing of any python file from any
                              > directory should exist in case loadpyplugin() is implemented.

                              It would be nice if you could include your idea about that function
                              in your gist:
                              https://gist.github.com/ZyX-I/5561409

                              I'm interested in the following details:

                              - where it should install the python code to (eg ~/.vim/pip or ~/.pip)

                              Document a simple real world example:
                              P: a plugin
                              D: a dependency of P
                              call loadpyplugin('P', ..) ?

                              - how you think a plugin writer should publish the plugin so that
                              everybody can use it easily (PyPi?)

                              - who is responsible for setting rtp, so that syntax/* etc will work

                              - setting sys.path so that P and X related module will be found

                              - if pip is going to install something, will it ask me? (VAM does)

                              - if pip is going to install a dependency, do I going to ask me (VAM
                              does)

                              - should it be possible that one plugin requires another one / two
                              plugins require each other?

                              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.
                            • ZyX
                              ... Done, copy-pasting here: ============== Plugin loading ============== The following is additional stuff to ease creating python-only plugins by adding
                              Message 14 of 25 , Jun 4, 2013
                              • 0 Attachment
                                вторник, 4 июня 2013 г., 10:59:06 UTC+4 пользователь MarcWeber написал:
                                > Excerpts from ZyX ZyX's message of Tue Jun 04 05:55:18 +0200 2013:
                                > > I am no longer seeing why automatic sourcing of any python file from any
                                > > directory should exist in case loadpyplugin() is implemented.
                                >
                                > It would be nice if you could include your idea about that function
                                > in your gist:
                                > https://gist.github.com/ZyX-I/5561409

                                Done, copy-pasting here:

                                ==============
                                Plugin loading
                                ==============

                                The following is additional stuff to ease creating python-only plugins by adding
                                basic plugin management support:

                                ``'pythoninstallprg'``/``'pip'`` and ``'python3installprg'``/``'pip3'`` options:
                                Specify what program is used by ``:pyload``/``:py3load`` commands below in
                                case importing failed.

                                ``:pyload[!] module.submodule[ args]`` (and ``:py3load``) commands:
                                Try to import ``module.submodule`` python module and run function
                                ``__viminit__`` from it. In case importing module fails runs
                                ``&pythoninstallprg . " " . args``. If there are no arguments uses
                                ``module`` (without ``.submodule``) as an argument. Does not run
                                ``&pythoninstallprg`` if bang was specified. If module was successfully
                                imported, but it does not contain ``__viminit__`` function it errors out.
                                Pseudo-code::

                                def pyload(module, args=None, bang=False):
                                try:
                                # Don't use this in real code, there is __import__!
                                exec('import ' + module + ' as m')
                                except ImportError:
                                if not bang:
                                vim.command('!'
                                + vim.options['pip' + ('' if sys.version_info < (3,) else '3')] +
                                + ' '
                                + (args or module.partition('.')[0]))
                                pyload(module, bang=True)
                                else: # Runs code if there was no exception, but outside of try: block
                                # May raise AttributeError. Or any other error occurred in __viminit__
                                m.__viminit__()


                                ``:confirm pyload`` should run confirmation before installing anything,
                                otherwise program is installed using regular ``!`` (well, underlying
                                C functions) without asking.

                                ``silent pyload`` should supress any messages and installation process
                                output like ``silent !pip install ...`` would do. I guess this part will be
                                gained "for free".


                                >
                                > I'm interested in the following details:
                                >
                                > - where it should install the python code to (eg ~/.vim/pip or ~/.pip)

                                Nowhere. It just calls pip and pip knows what to do.

                                > Document a simple real world example:
                                > P: a plugin
                                > D: a dependency of P
                                > call loadpyplugin('P', ..) ?

                                There is setup.py. Dependencies are specified there. loadpyplugin() is here *only* for users, never for plugins.

                                > - how you think a plugin writer should publish the plugin so that
                                > everybody can use it easily (PyPi?)

                                Anywhere reachable by pip. You can use 'git+git://github.com/Lokaltog/powerline' as a second argument to make pip install from that location.

                                > - who is responsible for setting rtp, so that syntax/* etc will work

                                We are talking about python-only plugins. What syntax/* or ftplugin/* in case of python-only? The only option here is using Filetype and Syntax events.

                                Mixed python/vim are supposed to be managed as usual: via Vundle/VAM or manual installation from vim.org. It is though possible that runtimepath is modified based on the __file__ variable, but this is the responsibility of plugin.

                                > - setting sys.path so that P and X related module will be found

                                It is the job of pip.

                                > - if pip is going to install something, will it ask me? (VAM does)

                                With the function: not. I guess this need to be changed into the command so that :confirm can be used to force asking. Unless specifically requested to confirm it won't ask anything.

                                > - if pip is going to install a dependency, do I going to ask me (VAM
                                > does)

                                Not in any case. Unless you take the pip sources and modify them to include something like --ask switch (this is why I added a note that `:pyload` will use regular `!`).

                                > - should it be possible that one plugin requires another one / two
                                > plugins require each other?

                                Python-only plugins are not supposed to depend on vim ones. Other dependencies are specified in the setup.py as usual. Main idea is that python already has a package manager thus we don't want to invent another one. You can specify anything as &pythoninstallprg though, even `emerge` (it won't work unless under root though). There are even more then enough python packages with `pip install` argument identical to `emerge` one (it does not matter though because arguments may be any: if given they are not preprocessed in any fashion).

                                > 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
                                You ve been missing documenting default settings .. ... May be counter intuitive. ! usually means force it . I understand the idea make things work by
                                Message 15 of 25 , Jun 4, 2013
                                • 0 Attachment
                                  You've been missing documenting default settings ..

                                  > Does not run ``&pythoninstallprg`` if bang was specified.
                                  May be counter intuitive. ! usually means "force it".
                                  I understand the idea "make things work by default".
                                  But i think it should be the user having the choice anyway.

                                  > > - where it should install the python code to (eg ~/.vim/pip or ~/.pip)
                                  > Nowhere. It just calls pip and pip knows what to do.
                                  So you also have to run PIP on each startup ! And thats taking time
                                  eventually. No idea how much.

                                  > Anywhere reachable by pip. You can use
                                  > 'git+git://github.com/Lokaltog/powerline' as a second argument to make
                                  > pip install from that location.

                                  > > - who is responsible for setting rtp, so that syntax/* etc will work
                                  > We are talking about python-only plugins. What syntax/* or ftplugin/*
                                  > in case of python-only? The only option here is using Filetype and
                                  > Syntax events.
                                  > [...]
                                  > runtimepath is modified based on the __file__ variable, but this is
                                  > the responsibility of plugin.
                                  So we support it this way. So we should create a sample plugin later.

                                  How to "backport" your stuff to older Vim? That's why I think that
                                  creating viml code is a better option for the beginning.

                                  What about introducing &pip_install_expr ?

                                  let g:pip_install_expr=pip#Install(v:package, true)

                                  where true means "want confirmation". Then user can easily replace the
                                  implementation.

                                  And you can get rid of allmost all options you've been talking about.
                                  And everybody can replace it easily by providing his own implementation
                                  if required.

                                  I think its much more flexible than having things built into Vim.
                                  Also what you built into Vim should be supported forever ..

                                  Using VimL means you can also support older vim installations easily.

                                  > Not in any case. Unless you take the pip sources and modify them to
                                  > include something like --ask switch (this is why I added a note that
                                  > `:pyload` will use regular `!`).
                                  I'm not against it. But I guess people want to know what is happening.

                                  Would you join a viml only implementation to get started with this all?
                                  Its also going to take less time than a Vim patch.

                                  > > - should it be possible that one plugin requires another one / two
                                  > > plugins require each other?
                                  > Python-only plugins are not supposed to depend on vim ones.
                                  I'd expect users thinking in objects of "this gets that feature done"
                                  not caring about those solutions being viml or python. The user should
                                  not care IMHO.

                                  > dependencies are specified in the setup.py as usual. Main idea is that
                                  > python already has a package manager thus we don't want to invent
                                  > another one.
                                  If we do - then let's have both: PIP and Vam/Vundle/etc
                                  But allow PIP to replace VAM.

                                  We should setup mirroring anyway. Who wants to unpack .tar.gz on Windows
                                  !? But thats another (future) story. Npackd like implementations would
                                  also benefit.

                                  Think about why this must be Vim patch. I think we can get reasonably
                                  close by just providing a autload/ file.

                                  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.
                                • ZyX ZyX
                                  ... He makes: when does (not) specify bang. ... ***! **IT DOES NOT RUN PIP.** By the time pip **HAD *ALREADY* DONE** all the necessary job. ... Just take my
                                  Message 16 of 25 , Jun 4, 2013
                                  • 0 Attachment


                                    On Jun 5, 2013 1:22 AM, "Marc Weber" <marco-oweber@...> wrote:
                                    >
                                    > You've been missing documenting default settings ..
                                    >
                                    > > Does not run     ``&pythoninstallprg`` if bang was specified.
                                    > May be counter intuitive. ! usually means "force it".
                                    > I understand the idea "make things work by default".
                                    > But i think it should be the user having the choice anyway.

                                    He makes: when does (not) specify bang.

                                    > > > - where it should install the python code to (eg ~/.vim/pip or ~/.pip)
                                    > > Nowhere. It just calls pip and pip knows what to do.
                                    > So you also have to run PIP on each startup ! And thats taking time
                                    > eventually. No idea how much.

                                    ***! **IT DOES NOT RUN PIP.** By the time pip **HAD *ALREADY* DONE** all the necessary job.

                                    > > Anywhere reachable by pip. You can use
                                    > > 'git+git://github.com/Lokaltog/powerline' as a second argument to make
                                    > > pip install from that location.
                                    >
                                    > > > - who is responsible for setting rtp, so that syntax/* etc will work
                                    > > We are talking about python-only plugins. What syntax/* or ftplugin/*
                                    > > in case of python-only? The only option here is using Filetype and
                                    > > Syntax events.
                                    > > [...]
                                    > > runtimepath is modified based on the __file__ variable, but this is
                                    > > the responsibility of plugin.
                                    > So we support it this way. So we should create a sample plugin later.
                                    >
                                    > How to "backport" your stuff to older Vim? That's why I think that
                                    > creating viml code is a better option for the beginning.

                                    Just take my pseudo-code from RFC with some minor modifications and a VimL wrapper. Except that you will have to use globals in place of options.

                                    > What about introducing &pip_install_expr ?
                                    >
                                    > let g:pip_install_expr=pip#Install(v:package, true)
                                    >
                                    > where true means "want confirmation". Then user can easily replace the
                                    > implementation.
                                    >
                                    > And you can get rid of allmost all options you've been talking about.
                                    > And everybody can replace it easily by providing his own implementation
                                    > if required.

                                    I was talking about only one option.

                                    > I think its much more flexible than having things built into Vim.
                                    > Also what you built into Vim should be supported forever ..

                                    This is the intention. Not building something into vim leads to creating bicycles by plugin authors. And I never saw anybody using functions defined in vim runtime files (except for vimball support in VAM). There must be a reason for it.

                                    > Using VimL means you can also support older vim installations easily.
                                    >
                                    > > Not in any case. Unless you take the pip sources and modify them to
                                    > > include something like --ask switch (this is why I added a note that
                                    > > `:pyload` will use regular `!`).
                                    > I'm not against it. But I guess people want to know what is happening.
                                    >
                                    > Would you join a viml only implementation to get started with this all?
                                    > Its also going to take less time than a Vim patch.

                                    It is not possible and not required. For python+viml implementation take code from RFC, replace exec and supply a wrapper.

                                    > > > - should it be possible that one plugin requires another one / two
                                    > > > plugins require each other?
                                    > > Python-only plugins are not supposed to depend on vim ones.
                                    > I'd expect users thinking in objects of "this gets that feature done"
                                    > not caring about those solutions being viml or python. The user should
                                    > not care IMHO.

                                    There is no standard plugin manager for VimL and none at all that may specify python dependencies.

                                    And it is not user who needs to care, it is developer. I bet depending on viml plugins will not be popular at all, so no need to care.

                                    > > dependencies are specified in the setup.py as usual. Main idea is that
                                    > > python already has a package manager thus we don't want to invent
                                    > > another one.
                                    > If we do - then let's have both: PIP and Vam/Vundle/etc
                                    > But allow PIP to replace VAM.

                                    Wondering how do you imagine this.

                                    And what this note is for: if you wish, you can already use VAM, Vundle and system package manager at a time. As far as they all manage different plugins it is fine.

                                    > We should setup mirroring anyway. Who wants to unpack .tar.gz on Windows
                                    > !? But thats another (future) story. Npackd like implementations would
                                    > also benefit.
                                    >
                                    > Think about why this must be Vim patch. I think we can get reasonably
                                    > close by just providing a autload/ file.
                                    >
                                    > 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.
                                    >
                                    >

                                    --
                                    --
                                    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
                                    ... I think its also lack of documentation, no wiki on vim.sf.net telling people how to do things. I ve made suggestion. But it looks like people don t care
                                    Message 17 of 25 , Jun 4, 2013
                                    • 0 Attachment
                                      Excerpts from ZyX ZyX's message of Wed Jun 05 00:00:31 +0200 2013:
                                      > This is the intention. Not building something into vim leads to creating
                                      > bicycles by plugin authors. And I never saw anybody using functions defined
                                      > in vim runtime files (except for vimball support in VAM). There must be a
                                      > reason for it.
                                      I think its also lack of documentation, no wiki on vim.sf.net telling
                                      people how to do things. I've made suggestion. But it looks like people
                                      don't care enough.

                                      > There is no standard plugin manager for VimL and none at all that may
                                      > specify python dependencies.
                                      Right - Vim itself does not have a standard. there is vim huge, vim
                                      tiny, vi, ..

                                      > And it is not user who needs to care, it is developer. I bet depending on
                                      > viml plugins will not be popular at all, so no need to care.
                                      Its about legacy code. You don't to rewrite all viml code, but you may
                                      want to use PIP. I'm thinking about existing code such as indentation
                                      expressions.

                                      > > If we do - then let's have both: PIP and Vam/Vundle/etc
                                      > > But allow PIP to replace VAM.
                                      > Wondering how do you imagine this.
                                      -> future story: Provide a single place to register plugins.
                                      Then provide .zip files for Windows, and pip install archives for pip.
                                      Currently there are only about 5000 packages to supoprt. Should be
                                      doable (coutning all packages VAM-kr knows about).

                                      Then you can install everything using pip only. All which must be done
                                      is adding a setup.py file - and esuring each plugin sets rtp.

                                      Then it replaces VAM.

                                      In the long run we want such repository anyway, so tha we can search in
                                      all plugin code (whether its python, viml or something else).


                                      There may be situations where you cannot / don't want to compile vim
                                      yourself. Using a runtimepath viml soultios would be an optoin.
                                      However Vim does not allow viml to provide builtin features.

                                      builtin: lower case
                                      viml: upper case

                                      So maybe this would be another thing which could be changed.
                                      It would be nice to provide :pyx_something commands for older vim
                                      implementations. There is no way, right?

                                      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.