Re: Request: suppression of plugins
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 knowledge what each plugin really is about, who is the maintainer, what is the URL for updates and - the point - how to disable it. Or, better, each plugin should support the same method for disabling itself. The header does not need to be anything complex, just a set of standardized comments at the beginning of plugin code with mandatory and non-mandatory metadata fields. Or in a separate metadata file, that's for discussion. With such metadata we can, for example, generate a list of plugins and call disable methods (or set disabling variables-flags) for some of them in .vimrc And it would be also much easier to find what some plugin is about - even for those which are not a part of any official distro package but downloaded from some site several years ago. My idea is to agree on the metadata set (and format), announce it and mark each plugin at vim.org which follows this policy. This would make the life with plugins easier. Milan It would also make plugin writing harder (in that plugin authors would *willy-nilly* have to rigidly adhere to a preset header format), and it would make *all* existing plugins invalid, incompatible, and good for the trashcan, since they don't yet include your proposed metadata comments, even less a separate metadata file. If your metadata is non-mandatory, then it serves no purpose: in that case, let's just keep what already exists, it fills the non-mandatory side of the requirement, so what are you griping about? Regards, Tony. -- The District of Columbia has a law forbidding you to exert pressure on a balloon and thereby cause a whistling sound on the streets. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 Regards, Tony. -- ... And malt does more than Milton can To justify God's ways to man -- A. E. Housman --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 be loaded by default in the first place, and that there is no consistency in how plugins currently work. 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. On the other hand, I do want the option to load the 'standard' plugins if desired (and especially I want users of my startup code to be able to do so if they want). To just load the standard plugins, you could temporarily modify the 'runtimepath' option in the vimrc (untested): set noloadplugins let s:sav_rtp =rtp letrtp = $VIMRUNTIME runtime! plugin/*.vim letrtp = s:sav_rtp Things that come to mind about this code: How about escaping inrtp and $VIMRUNTIME? No need IIUC: :let keeps the string value unmodified Do we also need the after-directory $VIMRUNTIME./after? There is no $VIMRUNTIME/after/. After-directories are for custom stuff (system-wide or single-user) to be run _after_ $VIMRUNTIME. Best regards, Tony. -- Pecor's Health-Food Principle: Never eat rutabaga on any day of the week that has a y in it. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 different from the current convention to name the variable g:loaded_x? 2) Easier: don't have the plugins load by default. Move them to a parallel extra directory, and then the person who wants to load x can do runtime extras/x.vim in the vimrc I basically agree that vim shouldn't load plugins that were not intentionally installed/enabled by the user. The downside of disabling those standard plugins would be though that newbies would have a more difficult time. 3) Harder: have the ScriptPre autocommand actually be useful. Allow the user to set a variable of some kind to tell vim to not continue loading this script. Or simply define those variables in your vimrc file? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 have it bundled. You've probably missed html_use_css - :let it to 1 to get some decent CSS-y HTML, instead of the how-the-internet-worked-in-1994 html generated by default. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 user defined command to have priority over the TOHtml command. Ex: I use Tabularize and would like to use it as T instead of Ta I think all these shouldn't be standard: let loaded_rrhelper = 1 let g:loaded_zipPlugin = 1 let g:loaded_vimballPlugin = 1 let g:loaded_tarPlugin = 1 let g:loaded_getscriptPlugin = 1 let loaded_gzip = 1 let loaded_spellfile_plugin = 1 Regards Dimitar Dimitrov --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 that there is no consistency in how plugins currently work. 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. On the other hand, I do want the option to load the 'standard' plugins if desired (and especially I want users of my startup code to be able to do so if they want). To just load the standard plugins, you could temporarily modify the 'runtimepath' option in the vimrc (untested): set noloadplugins let s:sav_rtp = rtp let rtp = $VIMRUNTIME runtime! plugin/*.vim let rtp = s:sav_rtp Things that come to mind about this code: How about escaping in rtp and $VIMRUNTIME? Do we also need the after-directory $VIMRUNTIME./after? -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
If automatically loading plugins, use these variables to disable certain of them. ... let g:loaded_getscriptPlugin = 0 getscriptPlugin.vim let g:loaded_gzip = 0gzip.vim let g:loaded_matchparen = 0 matchparen.vim let g:loaded_netrwPlugin = 0 netrwPlugin.vim let g:loaded_rrhelper = 0rrhelper.vim let g:loaded_spellfile_plugin = 0spellfile.vim let g:loaded_tarPlugin = 0 tarPlugin.vim tohtml.vim (See below) let g:loaded_vimballPlugin = 0 vimballPlugin.vim let g:loaded_zipPlugin = 0 zipPlugin.vim tohtml.vimconvert a file with syntax highlighting to HTML This one is irritating and cannot be blocked with a simple variable. Instead, the TOhtml command must be created, so create a bogus one. command -range=% TOhtml :echo TOhtml is not implemented If I'm right, the original request was not about technical possibility. It was about the standardization and ease of use. You can see above that this is not the case now: 1. there is no naming scheme for those variables now. The only way how to get their names is to examine the plugin code. This is not nice for the end user. 2. some plugins don't allow any nice way (tohtml is an example above) 3. it's not easy to get a list of all plugins wanting to be loaded with a meaningful description of each - see below 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 knowledge what each plugin really is about, who is the maintainer, what is the URL for updates and - the point - how to disable it. Or, better, each plugin should support the same method for disabling itself. The header does not need to be anything complex, just a set of standardized comments at the beginning of plugin code with mandatory and non-mandatory metadata fields. Or in a separate metadata file, that's for discussion. With such metadata we can, for example, generate a list of plugins and call disable methods (or set disabling variables-flags) for some of them in .vimrc And it would be also much easier to find what some plugin is about - even for those which are not a part of any official distro package but downloaded from some site several years ago. My idea is to agree on the metadata set (and format), announce it and mark each plugin at vim.org which follows this policy. This would make the life with plugins easier. Milan -- Milan Vancura, Prague, Czech Republic, Europe --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 is in the autoload/ directory and is only loaded if and when the plugin is used. For those plugins that take advantage of this feature, which is most of the standard plugins, the plugin/ directory code only holds the public interface (commands and maps which call functions residing in the autoload/ directory). Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
On Aug 11, 4:50 pm, Charles Campbell charles.e.campb...@nasa.gov 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't understand how it came to be that e.g. tohtml became a standard plugin loaded by everyone. To answer the criticism someone else raised, that apparently few have complained about the current system -- I posit that most people have never looked, and have no idea how much stuff gets loaded by default. It becomes noticeable on older hardware, where vim is no longer the spry and efficient editor it used to be, but has fallen victim (as have many of us, I'm afraid) to middle-age bulge. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
2009/8/10 ron r...@ronware.org: 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 loaded. How about simply setting 'noloadplugin'? I can't see a functional difference between this solution and your example 2. -- Cheers, Lech --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 lech.lor...@gmail.com wrote: 2009/8/10 ron r...@ronware.org: 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 loaded. How about simply setting 'noloadplugin'? I can't see a functional difference between this solution and your example 2. -- Cheers, Lech --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Request: suppression of plugins
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 want with the runtime command. 2) Set 'loadplugins' (the default), and set a list of variables that will short-circuit the loading of individual standard plugins. All but one of the standard plugins has a disabling variable, and the oddball can be worked around. Here's the list of variables (an excerpt from my own .vimrc): If automatically loading plugins, use these variables to disable certain of them. This is confusing - by setting the variable, the plugin file will still be read, but not executed beyond the load check. So, comment out the lines for the plugins you want to load. let g:loaded_getscriptPlugin = 0 getscriptPlugin.vim let g:loaded_gzip = 0gzip.vim let g:loaded_matchparen = 0 matchparen.vim let g:loaded_netrwPlugin = 0 netrwPlugin.vim let g:loaded_rrhelper = 0rrhelper.vim let g:loaded_spellfile_plugin = 0spellfile.vim let g:loaded_tarPlugin = 0 tarPlugin.vim tohtml.vim (See below) let g:loaded_vimballPlugin = 0 vimballPlugin.vim let g:loaded_zipPlugin = 0 zipPlugin.vim tohtml.vimconvert a file with syntax highlighting to HTML This one is irritating and cannot be blocked with a simple variable. Instead, the TOhtml command must be created, so create a bogus one. command -range=% TOhtml :echo TOhtml is not implemented -- + Gregory H. Margo gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Request: suppression of plugins
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 from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
