ANNOUNCE: TOVL
Marc Weber
The lib is an very early stage and much has still to be done. But let me
tell you what the main goals are and let me invite you taking action and
help me expand and enhance it.
If you don't have much time jump in and try:
(You may want to remove ~/.theonevimlib_config afterwards)
$ git clone git://mawercer.de/theonevimlib
add the contained core folder to your runtimepath:
set :runtimepath+=theonevimlib/core
and restart vim. Then execute
:TOVLConfig
You should see something like this:
============= snip ===================================================
dictionary=
example:dictionary=
commandName:string=ExamplePluginH
command:string=echo 'lo world to you from example plugin'
loadablePlugins:dictionary=
example:number=1
[### your editing config file /home/marc/.theonevimlib_config ##### ]
============= snip ===================================================
Try
:Help
to get more info. It tells you how to play with the example plugin
redefining a very simple command or removing it if you unlead the
plugin.
So what is this all about?
I feel vim.org is nice but the vim community is lacking one feature:
Something thate ruby, perl, php all do have: A way to get plugins fast
and automatically. Yes there is vimball. But it did never adress all
problems. Most of the plugins do contain mappings of the author. You
customize them, you update the plugin and your changes are lost. TOVL
tries to separate functionality (the lib part) from user interface
(configuration). Using a version control system such as git you'll be
able to up and dowgrade on the fly if something has gone wrong.
TOVL can evolve to a vim community project:
* get all the code at once but only run the code you really want
That's done by activating "plugins"
disk is cheap, your time is not!
* containing most useful scripts, mappings, code without bloat
Because using a git repository everyone can commit to and remove
or enhance code. This should result in a very nice vim library
everyone likes to work with.
* Make people starting to learn vim more productive because they
can jump in and enable those plugins without the need to
read all the vim tips.
* no longer waste dev time rewriting the same stuff again and again.
(such as template systems etc).. We should try to get all features
into one "plugin" and enhance that. I think there is still enough
which can be improved.
* 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)
* 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.
* more to be done.
Of course a lot of things are still missing in the configuration
editor: highlighting, completion, ... I'll add featuers piecwise.
(Maybe you want to help me?)
Please read the top level README and tell me about your feelings?
It is still a prototype. I need your input to make it even better.
It may become a replacement of most scripts. But at the beginning I'd
like to make it only a collection of exsisting scripts.
Sincerly
Marc Weber
Bram Moolenaar
Marc Weber worte:
Where can we read the help before doing all this?
It sounds rather complicated. And requires git (which I don't have
installed). What's wrong with ftp, which is available nearly
everywhere?
> So what is this all about?
> I feel vim.org is nice but the vim community is lacking one feature:
> Something thate ruby, perl, php all do have: A way to get plugins fast
> and automatically. Yes there is vimball. But it did never adress all
> problems. Most of the plugins do contain mappings of the author. You
> customize them, you update the plugin and your changes are lost. TOVL
> tries to separate functionality (the lib part) from user interface
> (configuration).
I like this part. The plugin only defines the functionality, it's up to
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.
> Using a version control system such as git you'll be
> able to up and dowgrade on the fly if something has gone wrong.
I think the whole idea of plugins is that you can rely on the plugin
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.
> TOVL can evolve to a vim community project:
>
> * get all the code at once but only run the code you really want
> That's done by activating "plugins"
> disk is cheap, your time is not!
>
> * containing most useful scripts, mappings, code without bloat
> Because using a git repository everyone can commit to and remove
> or enhance code. This should result in a very nice vim library
> everyone likes to work with.
If everyone can commit, how do you avoid people breaking someone else's
script? Or adding malicious stuff? You need access control. You need
to manage users. You need documentation. Doesn't this sound like a
SourceForge/code.google.com/etc. project?
> * Make people starting to learn vim more productive because they
> can jump in and enable those plugins without the need to
> read all the vim tips.
I stongly object to enabling something that you don't know what it's
going to do. Especially if you don't even know where it's coming from.
Every script you enable must have documentation you read before using
it. Unless it's part of a core set of plugins that everybody uses.
> * no longer waste dev time rewriting the same stuff again and again.
> (such as template systems etc).. We should try to get all features
> into one "plugin" and enhance that. I think there is still enough
> which can be improved.
Rewriting stuff can be much quicker than agreeing on "one way" and
putting everything into one. It depends.
> * 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.
> * 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.
> * more to be done.
>
> Of course a lot of things are still missing in the configuration
> editor: highlighting, completion, ... I'll add featuers piecwise.
> (Maybe you want to help me?)
>
> Please read the top level README and tell me about your feelings?
>
> It is still a prototype. I need your input to make it even better.
>
> It may become a replacement of most scripts. But at the beginning I'd
> like to make it only a collection of exsisting scripts.
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.
--
ARTHUR: I am your king!
WOMAN: Well, I didn't vote for you.
ARTHUR: You don't vote for kings.
WOMAN: Well, 'ow did you become king then?
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Tom Link
> > (You may want to remove ~/.theonevimlib_config afterwards)
> > $ git clone git://mawercer.de/theonevimlib
interface to peek what is about to be expected. Github or similar
providers would already provide such a web interface.
> I like this part. The plugin only defines the functionality, it's up to
> 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.
maps with a user customizable prefix. This function could be called
from some sort of after/vimrc.vim. In any case, such good practice
(which had to be defined by Bram) should best be described in the vim
help file.
> > * no longer waste dev time rewriting the same stuff again and again.
> > (such as template systems etc).. We should try to get all features
> > into one "plugin" and enhance that. I think there is still enough
> > which can be improved.
>
> Rewriting stuff can be much quicker than agreeing on "one way" and
> putting everything into one. It depends.
grand unified template system because sooner or later people would
start sharing templates. I actually think it would be best to
integrate one template system that provides a certain feature set (at
least those features I personally find useful ;-) into the standard
vim library.
Regards,
Thomas.
Marc Weber
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 marco-...@gmx.de (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
A. S. Budden
> http://github.com/MarcWeber/theonevimlib/tree/master
[snip]
> edit configuration file your editing config file
> /home/marc/.theonevimlib_config
I'm curious: why did you choose to keep the configuration separate to
the vim configuration? I would find this really awkward to use as I
keep all plugins and their configuration (and a few helpers like ctags
binaries and suchlike) in the vimfiles directory, which makes it easy
to synchronise (with subversion) over multiple (Linux & Windows)
computers. Having a (presumably) necessary configuration file outside
of .vim/vimfiles means that these settings don't get transferred.
Al
Marc Weber
>
> 2008/12/3 Marc Weber <marco-...@gmx.de>:
> > http://github.com/MarcWeber/theonevimlib/tree/master
> [snip]
> > edit configuration file your editing config file
> > /home/marc/.theonevimlib_config
> [snip]
>
> I'm curious: why did you choose to keep the configuration separate to
> the vim configuration?
to another location so that you can track it wit svn as well? it's even
better. You can define a function which returns the list of
configuration files. So you decide where to store this setup.
For details see http://github.com/MarcWeber/theonevimlib/tree/master/core/autoload/config.vim
option config.filesFunc. You can tweak it easily to merge project
specific setups as well.
The main reason is: There are many vim users out there. And you'll meet
some which already have mapped <F5> to functionality X. So your plugin
wants to map <F5> as well? What to do now? Keep local patches (using subversion?)
Force the other user to change his mapping? ...
That's why the separate configuration is the onlny way to go (IMHO)..
Wether it must look the way its done in the exapmle I don't know yet.
You can also use configuration option like this
dictionary : plugin =
dictionary : myplugin =
mappings_exec : string =
map <c-x> :call FooBar()<cr>
map <c-y> :call FooBar()<cr>
map <c-z> :call FooBar()<cr>
Note that you can enter multiline Strings this way easily..
So what makes this different from putting it into your .vimrc?
Its faster. You enable the plugin, reload (the plugin will add its
default to the config, but won't override settings which are already
present) . Then you can start customizing. You don't Have to open many
files. We'll add a command :ConfigHelp or such and you'll know what an
option is about. If you have to you can still dive into the code (which
you should for security reasons, see post by Bram). Keep feeding your
input and give me a chance to make this more valuable than a custom
setup.
mit freundlichem Gruss
Marc Weber
A. S. Budden
>
> On Wed, Dec 03, 2008 at 01:53:07PM +0000, A. S. Budden wrote:
>>
>> 2008/12/3 Marc Weber <marco-...@gmx.de>:
>> > http://github.com/MarcWeber/theonevimlib/tree/master
>> [snip]
>> > edit configuration file your editing config file
>> > /home/marc/.theonevimlib_config
>> [snip]
>>
>> I'm curious: why did you choose to keep the configuration separate to
>> the vim configuration?
> I don't see why you shouldn't be able to symlink ~/.theonevimlib_config
> to another location so that you can track it wit svn as well? it's even
> better. You can define a function which returns the list of
> configuration files. So you decide where to store this setup.
> For details see http://github.com/MarcWeber/theonevimlib/tree/master/core/autoload/config.vim
> option config.filesFunc. You can tweak it easily to merge project
> specific setups as well.
>
> The main reason is: There are many vim users out there. And you'll meet
> some which already have mapped <F5> to functionality X. So your plugin
> wants to map <F5> as well? What to do now? Keep local patches (using subversion?)
> Force the other user to change his mapping? ...
> That's why the separate configuration is the onlny way to go (IMHO)..
> Wether it must look the way its done in the exapmle I don't know yet.
> You can also use configuration option like this
Maybe I'm missing the point, but I still don't understand why this
file can't be ~/.vim/theonevimlib_config rather than
~/.theonevimlib_config - this won't make any difference to other users
as this file is only in MY configuration. Of course, if you can
customise the location of this config file (as hinted to in your post
with "You can define a function which returns the list of
configuration files.") then my concerns are irrelevant...
Al
Marc Weber
call config#SetG('config.filesFun',
\ "return ".string([expand('$HOME').'/.vim/someconfig']))
should do it.
Normally you would have used a function reference or library#Function('foo#Bar').
Strings can be used and will be executed instead.
Marc Weber
Taylor Venable
Marc Weber <marco-...@gmx.de> wrote:
> 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?
But most projects, let's take OpenBSD for example, don't have a totally
open commit process. I trust the small party of people who do examine
every single line of the kernel on my behalf, so there's no need for me
to look at it myself. And I only use what they publish, so I can be
reasonably certain the code is good. But in a world where anybody could
commit something, I could not trust it at all, because I cannot trust
the whole world.
> You have to take some risk. Who knows wether vim.org can be hacked as
> well?
Which is why most software is distributed with MD5 or SHA1 or SHA256
hashes along with signatures on those hashes, so you can be reasonably
certain that what you're downloading is what the author intended.
Features like this (done automatically by many package managers) would
be a nice addition.
> 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.
Just to be slightly humorous, how about *That* One Vim Library? :D
Package management in Vim is an interesting idea, though. Perhaps some
inspiration could be drawn from the attempts that other editors, e.g.
(X)Emacs have made in this arena as well.
--
Taylor Christopher Venable
http://real.metasyntax.net:2357/
How many shells could Shell sort
sort if Shell sort could sort shells?
Marc Weber
>
> On Wed, 3 Dec 2008 13:51:20 +0100
> Marc Weber <marco-...@gmx.de> wrote:
>
> > 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?
>
> But most projects, let's take OpenBSD for example, don't have a totally
> open commit process. I trust the small party of people who do examine
> every single line of the kernel on my behalf, so there's no need for me
> to look at it myself. And I only use what they publish, so I can be
> reasonably certain the code is good. But in a world where anybody could
> commit something, I could not trust it at all, because I cannot trust
> the whole world.
> > You have to take some risk. Who knows wether vim.org can be hacked as
> > well?
gonteoo, mandrake update server thereby preventing clients to get
security updates. Moreover the "update" server already had the ips of
its clients.. Anyway I think this is fixed because I've moved to github.
Only I have access to it. So you have to trust me :-)
Anyone else can send me pull requests though.
You still can push to mawercer without access restrictions. But I'll
review the patches before uploading them to github.
> certain that what you're downloading is what the author intended.
> Features like this (done automatically by many package managers) would
> be a nice addition.
So would you like to join and give some input while testing?
Perhaps some
> inspiration could be drawn from the attempts that other editors, e.g.
> (X)Emacs have made in this arena as well.
What can we learn from them? I've never used them to that extend.
Sincerly
Marc Weber
Marc Weber
function! Map(mode, ...)
if a:1== '<buffer>'
let buffer = '<buffer> '
let what = a:2
let args = a:000[2:]
else
let buffer = ''
let what = a:1
let args = a:000[1:]
endif
if !has('gui_running')
exec a:mode.'noremap '.buffer.substitute(substitute(what,'<m-\(.\)>','<esc>\1','g'),'<m-s-\(.\)>','<esc><s-\1>','g').' '.join(args,' ')
else
exec a:mode.'noremap '.buffer.what.' '.join(args,' ')
endif
endfunction
command! -nargs=* Noremap call Map('', <f-args>)
command! -nargs=* Nnoremap call Map('n', <f-args>)
command! -nargs=* Inoremap call Map('i', <f-args>)
command! -nargs=* Vnoremap call Map('v', <f-args>)
So that I can use Noremap instead of noremap everywhere.
It replaces <m-a> by <esc>a if there is no gui. This sucks but works
fine. At least I can share mappings this way.
Do you have better suggestions to get a similar result?
(I know about the suggestion made by LeoNerd..)
I'm thinking about which is the best way to add kind of hook to TOVL
so that I can apply the <m-a> to <esc>a conversion?
Maybe I should just map all <esc>char to <m-char> combinations?
How do you do this?
Sincerly
Marc Weber
Thomas Koch
thanks for your effort and your extra private mail. I do agree very much
with you, that the current state of plugins in VIM is horrible at least,
but I don't think that your proposed solution is the right one.
1. Distributions have their own package management system and their way
of shipping vim plugins[1]. And I prefer very much to use the package
management system of my distribution for updating and dependency
management.
2. Keep thinks independent! I really dislike the idea of hawing one big
thing containing many plugins. It's like in software programming:
Have many small, independent, solid, interchangeable blocks to build
great systems.
Sorry for the delay of my response and that I don't have the time to
investigate your proposal further, but the above two points are absolute
no gos for me.
As you asked me to join your effort, I ask you to join mine to refresh
the vim.org site! :-)
[1] see: http://pkg-vim.alioth.debian.org/vim-policy.html/
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
Marc Weber
next. I'd vote for a way to comment scritps. This would make things much
better.
On Sat, Dec 13, 2008 at 08:44:50PM +0100, Thomas Koch wrote:
> [..] I do agree very much
> with you, that the current state of plugins in VIM is horrible at least,
> but I don't think that your proposed solution is the right one.
>
> 1. Distributions have their own package management system and their way
> of shipping vim plugins[1]. And I prefer very much to use the package
> management system of my distribution for updating and dependency
> management.
The thing is : what is a plugin? I don't think it's worth creating a
debian plugin for 10 lines of script which can make your life easier.
But those 10 lines are worth making a small plugin and giving it some
minimal documentation so that those 10 lines can be found and used.
I was driven by some experiences when creating this new library:
a) Really the really nice database script. But what the fuck?
It did ask me again and again for 10 configuration values because I
accidently used a mapping or the wrong command?
(Even if I had run it intenionally it would'nt have been nice to use)..
b) Which tool to use if you have a list and want the user to pick one
item? use inputlist? It sucks because you have to type the number and
<cr>. That's one key too much. It also sucks because it doesn't print
the item numbers before the lines. so you do have to do this yourself..
I've implemented a solution using inputlist. It prefixes the lines
with its index so that you know which number to type. You also don't
have to type the trailing <cr> if the selection is not ambiguous.
Now I think kind (give the user a list and let it choose one item) is
very common. Does vim provide a really good builtin method for this?
Maybe I've missed it. I've spend time writing this function. Tom Link
has done much better. You have a list which you can filter. (Look for
TToC).. And I really think all plugins would benefit using those nice
functions. Why? Because its much faster. And you are already using vim
because it makes you fast.
Now consider the plugin policy: Where does vim run?
ubuntu, nixos (my favourite distro), debian, winxp,
vista, *bsd, gentoo, .. whatnot
Do you really want to ask all those package mantainers to packgage a lot
of scritps? And what about windos? Create Windows installer for 50 lines
of code? What a waste of time..
Do you know why eg ruby has been that succesfull? (Or pear..) You can
just get the code easily.. No matter which system you're using.
So I say : I disagree with that policy.. I want to use OS-packages for
* packages it would take me much time to compile them myself
* big packages which should be shared on the system (such as open
office)
Neither is true for vim scripts.
Now consider the case that such a "let the user select an item" function
changes its interface for whatever reason? If you have one code base the
one enhancing the function can use search and replace and eveything
works again. You prefer having many individual packages mantained by
different mantainers maybe the one doesn't know that the next uses his
function at all! The result must be broken code..
This even happend to me when trying to install tlib and the TToC
plugin although both have been written by the same mantainer..
If I hadn't installed the package before knowing that it did work well
maybe I would have given up. That's why I vote fore the "one" library
containing most useful code. That things can be enhanced and fixed more
easily. I even want to say you need this if you want to grow to get even
better scripts. And we all need better scripts (completions, code
navigation) because competitors such as Eclipse do exist. And they do
provide install and take off features. I fear that newcomers will use
Eclipse intead and not even try vim. That's bad for me because I do want
to use a system which will grow in the future as well. That's the main
reason why I've started TOVL. And if it doesn't work maybe I'll switch
to another solution in the future. But I don't want to because I love
vim.
For those newcomers (we all depend uppon in some way) a common question
is: How to become productive when editing
C or pyhton, or html, ....
and there are some things I learned only recently (although I've been
using vim for over 3 years now extensively).. One of those things is
that you should run php - l % to syntax check your file immediately
after writing. If you keep things separate you'le likely to miss a cool
feature which provides value to you.
If you have one library you can have a .txt help file for most common
use cases such as
a) Web developpemnt using
php
ruby
python
...
and least all the features. This way you won't miss them. Maybe you do
not use them but you've read about them.
Such a list will give you much more value than say www.vim.org and using
the search.. I also want a system which I can install within 2 minutes
to get productive somewhere else without backing up my ~/.vim before.
(backing up .vim is a solution for you. But its a nogo for me if you
want to share scripts because your .vim/ directory is very likely to
contain a lot of stuff someone else doesn't need! So what do you do?
Either you don't share (bad) or you start removing stuff first (bad - takes
time)..
I'v alread been telling you why disagree you on 2.:
> 2. Keep thinks independent! I really dislike the idea of hawing one big
> thing containing many plugins. It's like in software programming:
> Have many small, independent, solid, interchangeable blocks to build
> great systems.
May I quote you again :
" I do agree very much with you, that the current state of plugins in
VIM is horrible at least, "
^^^^^^^^
That's the point. It is neither great nor solid. There are
interchangeable blocks which do not work together without heavy
tweaking.
So why why why the hell is it that way? Vim is one of the oldest editors
around. So there should have been plenty of time to get this right. Why
didn't it happen? So something must be wrong with the current system.
I'd say terrible wrong. Nobody starts enhancing it because it takes to
much time for each individual person.
But why am I talking to you anymore. You already told me that you won't
have time.
Anyway: If you have a closer look at my README file (top directory)
you'll see that I've created two directories:
core/
contrib/
contrib was meant to contain many individual interchangable vim scripts.
However who does want to start tracking a 80 line script?
How much subrepositorie would you have then?
Git can handle this all easily. I've even written it down in the README.
You can even just add your old vim/{plugin,ftplugin,doc..} directory and
only use a small wrapper adding that directory to the runtime path on
demand. Support for this all is already there. I just do think that you
must have the chance to tidy up not only your plugin but also the code
of someone else. The benefits of this will be everyone will reading thus
writing better plugin code. And thats' a value to the community we
shouldn't miss.
So if anyone has some time left for discussion or for a small live
demontsration let me know. Ping me on irc or write an email. Don't waste
time. Ask. I'll happily point you to the lines in the documentation or
extend it.
So Thomas if you really think that the Debian policy is the way to go
what about seeing TOVL as the developement code base from which you can
extract complete plugins (only containing the necessary files)
automatically? Than Debian will have the hassle if package A got
updated to use C-2.0 but D still uses C1.-0 because there is no
mantainer anymore?
What is the alternative? use tovl and do a git pull (things will be
fixed soon because everyone will only fix some lines) or maybe reanme
C-2.0 to D puttting it into a different namespace so that you have to
start worrying about which one to use if you want to write plugins
others will use as well *not* using Debian?
Apart from that the Debian policy dosn't tell you anything about
* user configuration
* using autocommands to keep the amount of source beeing loaded on
start up as minimal as possible.
So its really even worse because you'll get some damn mappings only
because of the sys damin having had a great day installing new plugins
system wide ? (Maybe I'm wrong. I don't use Debian so correct me here,
please)
So maybe try the other way round and ask how TOVL tries to solve those
issues ?
Sorry for the long post. I had too much in my mind..
The problem I have is that nearly nobody even did try it to tell me
what's good and bad. That's a thing I don't understand: You've all spend
much time loaning vim. But you don't have some time left to try out TOVL
giving me feedback so that I can enhance doumentation and so on..
By the way the user interface abstraction should be very stable now.
You can extend it by adding different feature types. One type is
responsible for adding mappings, another for commands, the next for
adding completion functions and so one. So if your plugin introduces a
nice feature which could be used in many different contexts you can
expose it easily. I've done so for a kind of gf goto thing on cursor
handler. All it does is returning a list of locations. If you select one
which doesn't exist yet it'll be created. (neither gf nor gF do create
that resource..). so a goto handler doing roughle tha same as fg looks like this:
new library#Function("return [ expand('<CWODR>') ]")
This could be used to jump to header files in C /C++, to modules in
python.. (or even classes in Java). You get the idea.
Marc Weber
Thomas Koch
I'm sorry, but long emails like yours scare me and I did not have time
to read AND think about a response until today.
The next things to do for vim.org/scripts:
* summarize the requirements[1]
* get Bram to love the summarized requirements
* start a Design page in the wiki and propose a design: Programming
language, framework, ...
* I'd very much like to implement the new VIM site with eZComponents[2],
but it will get february until I'll get some free time for this
* I'm very convinced, that it would make sense to use GIT as the storage
backend for a new vim.org/scripts site. Old crufted CVS heros may use
a webinterface to upload new versions.
Parallel to the new vim.org/scripts site I propose the following:
Start to collect high quality vim scripts from vim.org and put them on
github.com (or alternatives). It would be nice to also have the version
history of the scripts in the repositories, but that's not so important.
It's much more important to get the licence informations right so that
distros don't have problems to include the scripts.
It would be great if we could convince vim script authors to publish
their scripts in GIT repos.
[1] http://vim.wikia.com/wiki/Vim.org_relaunch
[2] http://ezcomponents.org