http://github.com/MarcWeber/theonevimlib/tree/master
Click the (download) button.
Bram, I've made personal notes to you concerns below.
The help looks like this now:
use :GetContents to reload contents, ZZ or :w(q) to write and quit
Help for this scratch buffer:
=======================================================
edit configuration file your editing config file
/home/marc/.theonevimlib_config
Start by enabling the example plugin by setting the number to 1
Then write the buffer. This should load the plugin and add default
configuration options (commandName and command).
each time you change the settings and write them the plugin will get
notified
about those changes and will reload itself. Try running the command
ExamplePluginHW
and watch it changing..
If you remove the options (commandName and command) the plugin will add
them
for you again. This behaviour is plugin dependand.
Maybe you want to have a look at core/autoload/example.vim now?
Also make sure you've read the head comments in core/autoload/config.vim
It tells you how to use multiple (project specific) configuration files.
If you have any questions, don't know where to start or how to add your
code
write an email to [EMAIL PROTECTED] (I'm also on irc.freenode.net,
nick MarcWeber)
The example plugin looks like this (this has to improved.. But it
already works)
" link-doc: ./exmple.txt
" a basic plugin should define the following keys:
" load: this code will run by exec to setup plugin stuff.
" unload: this code should do the opposite. [optional]
" info: some short text about whot the plugin is supposed to do
" AddDefaultConfigOptions: Use this to add default configuration options
" be careful to not override user changes!
" Will be called before the main configuration
is
" shown for all activated plugins
function! plugins#example#Info()
return {
\ 'load': 'call plugins#example#Load()',
\ 'unload': 'call plugins#example#Unload()',
\ 'info': string('basic plugin demo'),
\ 'AddDefaultConfigOptions' : "call
plugins#example#AddDefaultConfigOptions()"
\ }
endfunction
function! plugins#example#Load()
call config#AddToList('config.onChange',
library#Function('plugins#example#OnChange'))
echo "loading example plugin stub"
let g:example_loaded = 1
let d = config#Get('example', {'default' : {}})
" make a copy of the settings to get to know wether something has
changed
call config#SetG('plugins.example.opts', deepcopy(d))
let cmdName = get(d,'commandName','ExamplePluginHW')
" remember command name so that we can remove it again..
call config#SetG('plugins.example.cmdName',cmdName)
exec 'command! '.cmdName.' '.get(d,'command','echo "unset"')
endfunction
function! plugins#example#Unload()
echo "unloading example plugin stub"
let g:example_loaded = 0
try
exec 'delc '.config#GetG('plugins.example.cmdName')
catch /.*/
endtry
endfunction
function! plugins#example#AddDefaultConfigOptions()
let g:g = "ward"
let d = config#Get('example', {'default' : {}, 'set' :1})
if !has_key(d, 'commandName')
call config#Set('example.commandName',"ExamplePluginHW")
endif
if !has_key(d, 'command')
call config#Set('example.command', "echo ".string("hello world to
you from example plugin"))
endif
endfunction
function! plugins#example#OnChange()
if config#GetG('plugins.example.opts') != config#Get('example', {})
" options have changed, reload
call plugins#example#Unload()
call plugins#example#Load()
endif
endfunction
Hi Bram,
about security:
You're right.
On the other hand have you had a look at all those C lines within the
kernel? Or all the other applications you are using?
I just hope that users will have a look at changes and revert them if
they are malicious the same way as spam is removed from Wikis.
You have to take some risk. Who knows wether vim.org can be hacked as
well? I haven't tried yet. But maybe we (who) can create a repo where we
add only reviewed patches..
Abouth the *one* lib you're right as well :-) But at least this naming
seems to gain some interest and forces discussion.. There can't be the
one solution. But there can be one coming closer to most needs.
> It sounds rather complicated. And requires git (which I don't have
> installed). What's wrong with ftp, which is available nearly everywhere?
tars and .zips are no availible.
Wrong with that is that you don't have history. You don't know what has
changed without adding a Changelog file.
> the user to bind this to keys. But how to avoid that the user has to
> set up a dozen maps for every plugin he installs? We still need
> defaults.
Try it. When you activate a plugin it will automatically add default
configurations whet refreshing the view..
> writer to make sure that a newer version works better. Having to check
> yourself is not nice. The excuse that you can go back a version is a
> bad excuse. Version control sounds like the wrong tool to me.
Many very popular projects (such as mootools and git itself) do it this
way.
> If everyone can commit, how do you avoid people breaking someone else's
> script?
Try to add some tests as I've done as well. There is no better solution.
I hope that the work of others will enhance things more often than break
them. But we have to give it a try.
> to manage users. You need documentation. Doesn't this sound like a
> SourceForge/code.google.com/etc. project?
Of course it is. But I hope to get more participants by not forcing
people to use logins. Maybe using github is the better way. That's why
I've moved.
> Especially if you don't even know where it's coming from.
Yes. I should really add a disclaimer and mike this more clear to
everyone. I agree.
> Rewriting stuff can be much quicker than agreeing on "one way" and
> putting everything into one. It depends.
Again: You don't have to use it. Just create a new plugin and put into
its description:
"This is an alternative to plugign XY", add this information to the old
one as well and everyone can decide on his own. But these references are
missing on vim.org
> > * maybe integrate a dependency system to create isntaller only
> > adding the library files which are actually needed.
> > (Some of the code is already there. But I still have to clean it up)
>
> It's best to resolve dependencies the moment you get a plugin. Not when
> using it. The autoload mechanism works well. We do need some way to
> handle shared autload scripts.
Maybe you got me wrong. Example
=============== plugin_file.vim =========================
function! plugins#example#Info()
return pluigns#utils#SetupCommands([
\ "map <m-f> : echo foo"])
endfunction
=========================================================
Now the plugin creating the installers should know that it has to
include autoload/plugins/utils/SetupCommands.
If you have a closer look at the example.vim file you'll note the line
" link-doc: ./exmple.txt
Which will be a hint for such an installer to also include the doc file
automatically.
> > * don't ever override configurations by accident while running
> > multiple vim instances. Configuration changes are written to
> > disk and reloaded by the other instances automatically.
> Amazing.
Not really. It just uses getftime each time you require an option..
You can use the function config#ScanIfNewer(file, opts) yourself to
cache all sorts of (maybe preprocessed) file contents. I do this to get
a function completion list for all functions found in any autoload dir
of all runtimepaths.
> I have mixed feelings about this. A claim to have the one and only
> solution to a problem is usually false. But there can be some useful
> parts here.
Just keep putting input so that we can turn this all into much more joy
for everyone.
Thanks!
Marc Weber
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
