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

pythonx patch - :pyx command

Expand Messages
  • Marc Weber
    There are two important problems with python support: 1) you still have to use .viml in order to load python 2) when using python its you having to remember
    Message 1 of 25 , May 31 9:17 AM
    • 0 Attachment
      There are two important problems with python support:
      1) you still have to use .viml in order to load python
      2) when using python its you having to remember which python to use despite
      most codes may work with python and python3 interpreter.
      Using the same (only one) interpreter is very important, because
      many vims will only support one, and loading both is slower

      So this patch
      - introduces the the option loadpyplugins, which is disabled by default
      like loadplugins it tells vim to load plugin/*.py files
      - Special commands like "# requires python 2.x" can be used to force Vim using
      pyfile or py3file. If such a comment is missing the pythonx python version setting
      is used to decide upon which interpreter to use. Obviously this setting
      should be set early in your .vimrc and not be touched again
      Likewise there are :pyxfile :pydo :pythonx :pyx pyxeval() to run python code
      depending on 'pythonx' setting.
      - adds some of the commands to python.vim syntax 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.
    • James McCoy
      ... despite ... This is only true if you don t support older versions of Python 2.x. Such a suggestion was already discussed in this thread:
      Message 2 of 25 , May 31 9:39 AM
      • 0 Attachment


        On May 31, 2013 12:17 PM, "Marc Weber" <marco-oweber@...> wrote:
        >
        > There are two important problems with python support:
        > 1) you still have to use .viml in order to load python
        > 2) when using python its you having to remember which python to use despite
        >   most codes may work with python and python3 interpreter.

        This is only true if you don't support older versions of Python 2.x. Such a suggestion was already discussed in this thread:
        http://thread.gmane.org/gmane.editors.vim.devel/38261

        --
        --
        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 didn t see a clear winner. We have py and py3, so people can choose whatever they like. Things like let dir = foo pyx import shutils;
        Message 3 of 25 , May 31 10:29 AM
        • 0 Attachment
          Excerpts from James McCoy's message of Fri May 31 18:39:13 +0200 2013:
          > This is only true if you don't support older versions of Python 2.x. Such a
          > suggestion was already discussed in this thread:
          > http://thread.gmane.org/gmane.editors.vim.devel/38261

          I didn't see a clear winner. We have py and py3, so people can choose
          whatever they like.

          Things like
          let dir = 'foo
          pyx 'import shutils; shutils.rmtree(vim.eval(dir))'

          do work with python 2 and 3 flawlessly. I also expect users to do this:

          pyx 'if sys.version == 2 then import python-2-implmentation else import python-3-implementeation'

          if both implementation support the same interface you can continue using
          pyx for all of your mappings without this if has(..) else do the same
          nonsense.

          I agree that this only makes sense using python 2.6,2.7 or newer which I
          think is very common today.

          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.
        • Bram Moolenaar
          ... I think it s a good idea to help people write portable Python plugins. We want to avoid that every plugin has to be written twice. Not everything is
          Message 4 of 25 , May 31 11:49 AM
          • 0 Attachment
            Marc Weber wrote:

            > There are two important problems with python support:
            > 1) you still have to use .viml in order to load python
            > 2) when using python its you having to remember which python to use despite
            > most codes may work with python and python3 interpreter.
            > Using the same (only one) interpreter is very important, because
            > many vims will only support one, and loading both is slower
            >
            > So this patch
            > - introduces the the option loadpyplugins, which is disabled by default
            > like loadplugins it tells vim to load plugin/*.py files
            > - Special commands like "# requires python 2.x" can be used to force Vim using
            > pyfile or py3file. If such a comment is missing the pythonx python version setting
            > is used to decide upon which interpreter to use. Obviously this setting
            > should be set early in your .vimrc and not be touched again
            > Likewise there are :pyxfile :pydo :pythonx :pyx pyxeval() to run python code
            > depending on 'pythonx' setting.
            > - adds some of the commands to python.vim syntax file

            I think it's a good idea to help people write portable Python plugins.
            We want to avoid that every plugin has to be written twice.

            Not everything is compatible between Python 2 and 3 though. Is there a
            way to do:

            if python3:
            do-it-this-way
            else:
            do-it-that-way

            Then :pyx would really work. Is that possible without getting errors
            for some code that works only in one versin?

            In the patch the docs have the section "Python 3" twice.

            The default for 'pythonx' should be zero when build with both Python 2
            and 3. Then the first Python command sets it.

            Should be called 'pythonversion' actually.


            --
            hundred-and-one symptoms of being an internet addict:
            30. Even though you died last week, you've managed to retain OPS on your
            favorite IRC channel.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            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
            ... 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
            Message 5 of 25 , May 31 1:05 PM
            • 0 Attachment
              пятница, 31 мая 2013 г., 20:17:45 UTC+4 пользователь MarcWeber написал:
              > There are two important problems with python support:
              >
              > 1) you still have to use .viml in order to load python
              > 2) when using python its you having to remember which python to use despite
              > most codes may work with python and python3 interpreter.
              > Using the same (only one) interpreter is very important, because
              > many vims will only support one, and loading both is slower
              >
              > So this patch
              > - introduces the the option loadpyplugins, which is disabled by default
              > like loadplugins it tells vim to load plugin/*.py files

              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.

              Also about the patch style: //style comments are not used in Vim; you are missing tabs inside functions for even-level indentation.

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

              Even with the latter fixed I would only put some necessary initialization into such files thus

              a) it would be fine for me to source file with locals() and globals() dictionary (one for both) created just before running file and Py_DECREFed immediately after (this has additional benefit of nearly forcing splitting python plugin into modules in python*/ and initialization in pyplugin/**.py: you can still put all the code into one file, but the result will look a bit hacky (you need to import __main__ and assign to its attributes; powerline does use this hack though, but only due to inability to use python callables in a same way as built-in funcrefs; and it is hacky only "a bit": normally you don't have much things to record in __main__)) and
              b) I would merge this at the same time with merging `sys.path` addition once it is implemented.

              For Bram: it would be better to merge this patch at the same time with patch with `_vim_paths_` special path in `sys.path` which will be eventually created. Otherwise there will either be yet another bicycles for appending things to `sys.path` or unreadable all-code-in-one-file plugins: it is easier to write them without built-in support for splitting module into a file.

              > - Special commands like "# requires python 2.x" can be used to force Vim using
              > pyfile or py3file. If such a comment is missing the pythonx python version setting
              > is used to decide upon which interpreter to use. Obviously this setting
              > should be set early in your .vimrc and not be touched again
              > Likewise there are :pyxfile :pydo :pythonx :pyx pyxeval() to run python code
              > depending on 'pythonx' setting.
              > - adds some of the commands to python.vim syntax file

              --
              --
              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
              ... It is possible, check out powerline for example. Most of time it does not use such straightforward approach though: try: from __builtin__ import unicode #
              Message 6 of 25 , May 31 1:10 PM
              • 0 Attachment
                > Not everything is compatible between Python 2 and 3 though. Is there a
                > way to do:
                >
                > if python3:
                > do-it-this-way
                > else:
                > do-it-that-way
                >
                > Then :pyx would really work. Is that possible without getting errors
                > for some code that works only in one versin?

                It is possible, check out powerline for example. Most of time it does not use such straightforward approach though:

                try:
                from __builtin__ import unicode # Python 2
                except ImportError:
                unicode = str # Python 3

                , but if one needs it there is

                if sys.version_info < (3,):
                # Python 2
                else:
                # Python 3

                > In the patch the docs have the section "Python 3" twice.
                >
                > The default for 'pythonx' should be zero when build with both Python 2
                > and 3. Then the first Python command sets it.
                >
                > Should be called 'pythonversion' actually.

                Maybe 'pythonxversion'? One key longer, but it makes clear who uses this option.

                --
                --
                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
                ... Example taken from UltiSnips: ./py-code/UltiSnips/compatibility.py ./py-code/UltiSnips/compatibility_py2.py ./py-code/UltiSnips/compatibility_py3.py
                Message 7 of 25 , May 31 8:25 PM
                • 0 Attachment
                  Excerpts from Bram Moolenaar's message of Fri May 31 20:49:45 +0200 2013:
                  > Then :pyx would really work. Is that possible without getting errors
                  > for some code that works only in one versin?

                  Example taken from UltiSnips:
                  ./py-code/UltiSnips/compatibility.py
                  ./py-code/UltiSnips/compatibility_py2.py
                  ./py-code/UltiSnips/compatibility_py3.py

                  Everything else is shared.

                  Of course

                  if py2:
                  print "foo"
                  else:
                  print("foo")


                  will not work, but stdout.write("foo\n") would work for both.
                  Also you could move the code into modules:

                  if py 2:
                  import py2
                  else:
                  import py3

                  There are also some module which can be loaded improving compatibility:
                  http://pythonhosted.org/six/

                  However I never used such.

                  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
                  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
                  Message 8 of 25 , May 31 8:44 PM
                  • 0 Attachment
                    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.

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

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

                    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?

                    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?

                    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.
                  • 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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.