2009/8/10 ron :
> Each suggestion has pros and cons. The ScriptPre is the only one
> which would have no effect on existing instalations, so perhaps Bram
> will prefer it to the others. I personally prefer the second
> suggestion, as in that case the user is in complete control over what
> gets
I don't want to disable all plugins. I want to disable some plugins,
and 'loadplugins' doesn't permit a "blacklist" or something.
On Aug 10, 9:36 am, Lech Lorens wrote:
> 2009/8/10 ron :
>
> > Each suggestion has pros and cons. The ScriptPre is the only one
> > which would have no effect on ex
On Mon, Aug 10, 2009 at 12:06:09AM -0700, ron wrote:
> I don't want to disable all plugins. I want to disable some plugins,
> and 'loadplugins' doesn't permit a "blacklist" or something.
There are two possible methods.
1) Set 'noloadplugins' and then explicitly load the individual plugins you
Right, I understand that -- and that is the same sort of ugliness I
have in my own 'vimrc'.
My point isn't that it is currently impossible -- but rather that we
have to go through silly steps to suppress what should really not be
loaded by default in the first place, and that there is no consiste
Please bottom post on this list. Quote a small (relevant) part
of the message you are replying to, and put your text underneath.
See the list guidelines:
http://groups.google.com/group/vim_use/web/vim-information
--~--~-~--~~~---~--~~
You received this message f
On 11-Aug-09 6:23, ron wrote:
> Right, I understand that -- and that is the same sort of ugliness I
> have in my own 'vimrc'.
Beauty is in the eye of the beholder. IMHO, the current plugin load mechanism
works perfectly fine for the vast majority of users.
> My point isn't that it is currently i
ron schrieb:
> Right, I understand that -- and that is the same sort of ugliness I
> have in my own 'vimrc'.
>
> My point isn't that it is currently impossible -- but rather that we
> have to go through silly steps to suppress what should really not be
> loaded by default in the first place, and
> " If automatically loading plugins, use these variables to disable
> " certain of them.
...
> let g:loaded_getscriptPlugin = 0" getscriptPlugin.vim
> " let g:loaded_gzip = 0 " gzip.vim
> " let g:loaded_matchparen = 0 " matchparen.vim
ron wrote:
> [snip]
> I use plugins for my own code, I don't want to disable them. But I
> don't want to load a whole bunch of code I never use, either.
[snip]
Are you aware of the bifurcation of the plugins into a plugin/ directory and
an autoload/ directory? The majority of the plugins' code
> I can imagine that something like "plugin registration" would help here
Yes, precisely correct. Thank you, Milan.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--
On Aug 11, 4:50 pm, Charles Campbell
wrote:
> Are you aware of the bifurcation of the plugins into a plugin/ directory and
> an autoload/ directory?
Yes, and I use it in my own plugin system. Nevertheless, the standard
plugins are not standard in how they can be disabled. And I truly
don'
Hi,
I just wanted to support all the complainers.
Even if the standard plugins do not slow Vim down, some of them are useless.
tohtml for instance produces code which is not compliant with any modern
standards. It is a shame to have it bundled.
Besides, even if I never use it, I would like other
On Wed, Aug 12, 2009 at 4:42 AM, Dimitar DIMITROV wrote:
> Hi,
>
> I just wanted to support all the complainers.
> Even if the standard plugins do not slow Vim down, some of them are useless.
> tohtml for instance produces code which is not compliant with any modern
> standards. It is a shame to h
> 1) All standard plugins supplied by vim should have a common method of
> suppressing their loading. That is, they should all have a common
> variable name to suppress them. For example, to suppress plugin "x",
> a variable "g:plugin_x_loaded" should be set or something.
How would this be diff
On 11/08/09 11:07, Andy Wokula wrote:
>
> ron schrieb:
>> Right, I understand that -- and that is the same sort of ugliness I
>> have in my own 'vimrc'.
>>
>> My point isn't that it is currently impossible -- but rather that we
>> have to go through silly steps to suppress what should really not b
On 11/08/09 11:41, Milan Vancura wrote:
[...]
> I can imagine that something like "plugin registration" would help here. Same
> as each plugin has a code part and doc part now, it would contain something
> like a registration part (a header with metadata), useful for several
> purposes:
> better
On 10/08/09 06:22, ron wrote:
[...]
> 3) Harder: have the "ScriptPre" autocommand actually be useful.[...]
There is no ScriptPre autocommand event. Maybe you mean SourcePre?
Beware that it is called for _every_ source command. Maybe even (I
haven't tested) when starting on your vimrc...
Best
17 matches
Mail list logo
