Saturday, November 27, 2010

Re: Emacs' Org-mode clone for Vim

> > 1. Do not pollute buffer and global scopes with lots of variables: either use
> > two dictionaries (one global and one buffer) which will hold all of them (for
> > example, see how it is implemented in vim-addon-manager), or do as I do: purge
> > out all global and buffer variables, use script-global dictionary with buffer
> > numbers as keys to emulate buffer-local variables and just script variables for
> > other purposes.
>
> Zyx -- That's an interesting approach.  My main plan has been to go
> through and refactor at some point (probably coming soon now) to make
> sure all the globals have a prefix of 'org_' or something else that
> would diffferentiate them from other plugins.

I slightly disagree with ZyX on that. IMHO global variables should be
used to allow users to configure your script. It is common practice
that users set that variables in their vimrc file and that the plugin
defines that variable only if it hasn't already be set by the user.

in vimrc:
let g:org_foo = 1

in org.vim (or whatever the plugin file is called):
if !exists('g:org_foo') | let g:org_foo = 0 | endif
if !exists('g:org_bar') | let g:org_bar = 0 | endif

If you maintain all user-configurable parameters in a single
dictionary, there is a chance you make it harder for users to
configure your scripts. Or you'd have to check for the existence of
single keys:

in vimrc:
let g:org = {'foo': 1}

in org.vim
if !exists('g:org') | let g:org = {} | endif
if !exists('g:org.foo') | let g:org.foo = 0 | endif
if !exists('g:org.bar') | let g:org.bar = 0 | endif

So, there's an extra step involved and I'm not sure it get you
anything.

If you emulate buffer-local variables with dictionaries, you'd have to
take care to remove those buffer settings when deleting the buffer. If
you use buffer-local variables, vim does that for you.

IMHO you should definitely prefix your global variables with the
plugin name though. And you should use script-local variables where
possible (i.e. for variables, the user shouldn't know about or
shouldn't change).

--
You received this message from the "vim_use" 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

No comments: