On Jun 1, 2013 7:43 AM, "Marc Weber" <[email protected]> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
