пятница, 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
