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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
