Tony Mechelynck <[EMAIL PROTECTED]> wrote :
> I agree about "doc"; but it seems to me that "autoload" would not
> necessarily be required for every ftplugin. On the contrary: I see why
> to use autoload for _global_ plugins: load a stub at startup and use
> autoload only if the plugin's functionality is actually used. But a
> ftplugin, indent, syntax, compiler, etc. are only sourced when a file
> of that filetype is opened -- so I don't see any gain from having part
> of the plugin in an autoload script.
I the case of official ftplugins, I agree with you, we will not gain
much from autoload plugins -- as official ftplugins are quite simple.
In the case of complex suites of ftplugins (see LaTeX-Suite, my C&C++
suite, etc), we have much to gain.
* When a ftplugin provides a really complex feature like analysing
a C++ function signature, there is no need to always import all the code
that does the analysis when we open a file of the supported filetype.
The analysis code needs to be loaded only when the vim end-user triggers
an action that needs the result of the analysis (automatic doxygenation
of a function, generating the function definition for a given function
signature).
In the end, the ftplugins will only contain mappings, commands,
abbreviations and settings, while autoload plugin will contain all the
routines that do the work.
* Factor common code. For instance, this code analysis routines will be
needed by to different C++ ftplugins : the one that doxygens a
signature, and the one that jumps to a function definition.
As I said in my other email, we could have used a simple "runtime
macro/{ft}-foo-API.vim"
NB: I'd rather have 15 different specialized C++ ftplugins, than only
one which is bloated with unrelated features. This way it is easier to
maintain, or to teel to a user "delete (/override) file foo.vim if you
don't want (/want to alter) /foo/ feature.
With this factorized code, it should be also easier for other scripts
writers to provide new functionalities built on top of our "ft-library".
* A nice name for our functions. I prefer
lh#cpp#AnalysisLib_Function#GetListOfParams() to
LH_cpp_AnalysisLib_Function_GetListOfParams() -- this one is a very
subjective argument.
PS: my C&C++ suite code has been under migration to autoload plugins for
several months now; the current state hasn't been released yet.
Best regards,
--
Luc Hermitte
http://hermitte.free.fr/vim/
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
