Hello,
> Disclaimer: I don't feel directly concerned as my vim distribution
> are the sources from svn (for solaris), or the cream-lite one (i.e.,
> without cream itself).
Ok. Maybe I should define a bit more, what I understand to be a
"distribution".
I think of distribution not only of some batteries-included vim package,
but also some system-installation. I worked as a system administrator
during my study time and was responsible for 40 public dialog stations,
where the students of our faculty could work. I consider it good
practice to provide the users a comfortable system. If the first thing,
they have to do, is to start installing software in their home
directory, I did something wrong. So I'd also like to preinstall some
of the more popular plugins.
> But, I see very well the problem at hand you want to solve. And I
> must admit, that at times it would be much simpler than the "mv
> {,inhibited/}plugin/fooplugin.vim" that I use. (bash syntax)
And this does not work, if the plugins where installed in the system
vimfiles hierarchy...
> How does this solve the problem of the distribution of old plugins
> that don't use gatekeeper? I'm not sure the vim maintainers for the
Obviously it does not. The scripts have to support gatekeeper, although
the loadplugins option, mentioned in another mail could be a rather
harsh helper here.
> How can it prevents "runtime! plugin/*.vim"?
Obviously it can not. It lives from cooperation. If the scripts use
gatekeeper, using runtime! or not makes no difference, since the scripts
obey to the user settings. If they don't, well, then they don't...
I also can't force a plugin to use <Leader>. If the author chose not to
use it, I have to live with it or patch the plugin.
> Which doesn't help us, script maintainers to reload a plugin.
> Well, to be honest, it not really a problem as we can always comment
> the finish line (as long as we don't forget to restore it later).
> However, now my plugins checks a exists("g:force_reload_{plugin}") in
> the first test.
I disagree. Obviously instead of modifying your plugin*s*, you would
just have to add the force flag to the central Guard function and *all*
your scripts support your flag immediately.
> BTW, I've seen an anti-reinclusion guard in your autoload plugin. In
> my experience, it serves no purpose as autoload plugins already hide
> away all the dependencies checks we had to do by hand in
> interdependent plain plugins.
Good point. I saw this in other autoload plugins, and since it was the
"traditional way" I didn't really think about that.
> > Further versions could even consider certain versions of a script,
> > or inter-plugin dependencies.
> This should disappear at terms thanks to autoload plugins. (Well, I
> hope so)
Well the original question about dependencies came up as the following
scenario: The user disabled a script explicitly and then some other
script depends on it. What happens now? We could simply source the
dependencies ignoring the user's choice or we obey to his wish. Then we
need some feedback. With autoload the user just gets a "E117: Unknown
function: foo#Bar". Oeeh... and now? Maybe a "Script foo needs plugin
bar, but it is disabled" or "Script foo needs plugin bar, but it seems
to be missing from runtimepath" is maybe more helpful. Or even an
interactive question, which let's the user decide immediately, whether
to enable the dependency (if the script is installed, but disabled).
> Indeed, it seems so. It could also be interesting to use gatekeeper
> as an interactive plugin that let the end user select what he wants.
One could check, which plugins are present, ask what the user wants to
do about them and save the state for future use. The user could invoke
the same procedure at any time to reconfigure his settings. Maybe it
could also recognise "new" plugins and give some feedback back to the
user. Of course only in case he chooses to receive such notifications.
Otherwise we stay out of his way.
This would need a bit more thought, how this could be worked out.
> Moreover, all my headers are generated with a template-files expander
> that provides the adequate anti-reinclusion guards for plugins (1
> global guard), ftplugins (1 global + 1 local guards), local_vimrcs
> (1local + 1 global), or whatever other vim script (0 guard).
This sound like a very special setup. It is hard (if not futile) to try
to cover all cases. What's of course possible, is to replace the central
Guard function. So there also some flexibility into this direction.
This is limited by the public API of course...
> What is hidden in this last sentence, is that gatekeeper does not
> help with ftplugins. When the ftplugin is just one file, blocking it
> is easy. When it is a suite made of many plugins, and ftplugins,
> blocking it with one assignment in the .vimrc becomes a much more
> complex task, and the call cannot even be used as an anti-reinclusion
> guard (see for instance LaTeX-Suite (or my C&C++ suite, which I don't
> distributed in any distribution before a very long time)).
Hmm.. This is another point, which needs some thought. I didn't think
about multi-file scripts.
> "over _compliant_ plugins", and only plugins. Unless vim is more
> deeply patched.
We have to live with the environment vim gives us. I highly appreciate
the freedom I have, when writing a plugin and how things can be done.
But sometimes freedom is bad: there are still plugins which don't adhere
to <(Local)Leader>. So without cooperation it doesn't work. No.
(A harsh workaround may be the loadplugins option...)
> Except it becomes a new dependency itself. If it ever becomes an
> official part of vim, this means, that we will have to maintain two
> branches of our plugins for (a little less than) a couple of years,
> the time everybody migrates towards a recent enough version of vim.
This is a problem, I cannot solve. One can use :try to optionally use
the "traditional" guard header. However then one would need :try. This
just shifts the problem.
> In conclusion, that's a very interesting idea. But I'm afraid this is
> not as simple as it looks like.
To cite my boss: "If it was easy, one wouldn't need us!" ;)
What is really surprising to me is, there seems to be a "need" of some
sort, since almost everyone says: Nice idea. As I understood Debian
even has some Ruby script which links scripts into the home
directory .vim of the user.
Yet, there is no solution to the problem.
Sincerely
Meikel
--
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_..;\ ( `'-'
'---(_/--' `-'\_) fL http://ec.kotka.de
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
