Proposal: "Modes" for Vim
krischik
Recently I was on the lookout for some Clearcase support for Vim and
searching for "Clearcase" revealed three different scripts from three
different maintainers. And I was thinking: Is that really "State of
the art"?
Quite a while ago I adopted the maintainer ship of the various Ada
plug ins for Vim. And by taking over all of them (syntax, file type,
indent) at once I was able to remove quite a bit redundancy.
Later with the Vim 7 features (namely: auto-load, lists and
directories) this trend even improved. For example I keep a list of
keywords, types, pragmas and then use them for both code completion
and syntax highlight.
I invite your all to have a look at the current Ada Mode [1]. "Mode"
because that it was the Emacs Guys call a collection of syntax, file
type, indent, etc.pp plug ins which work together. And here especially
the autoload/ada.vim.
My proposal (if you have not guessed already) is to merge more
separate plug ins into modes. What do you think about the idea?
Martin
Richard Hartmann
> My proposal (if you have not guessed already) is to merge more
> separate plug ins into modes. What do you think about the idea?
While I do not maintain any vim plugins, this suggestion makes
sense to me.
Richard
Doug Kearns
On 8/27/07, krischik <kris...@users.sourceforge.net> wrote:
<snip>
> My proposal (if you have not guessed already) is to merge more
> separate plug ins into modes.
We do something similar with http://vim-ruby.rubyforge.org/ which
distributes all of the 'official' Ruby related runtime files in a
single package.
> What do you think about the idea?
In general I think it's a good idea but what exactly are you
proposing? How would this work in practice?
Regards,
Doug
Charles E Campbell Jr
>My proposal (if you have not guessed already) is to merge more
>separate plug ins into modes. What do you think about the idea?
>
>
Well, it sounds like a "mode" is a combination of three plugins (syntax,
indent, ftplugin), and you want one person to maintain them all for a
specific language as you did for clearcase. In the case of some of the
syntax highlighting plugins I'm maintaining (tex, vim, sh, lisp, csh),
that would either mean I give up maintaining the syntax highlighting
plugins I wrote or taking on a bunch of other folk's plugins. I can't
say I'm enthusiastic about taking on maintenance for other's plugins (I
have quite enough maintaining already!).
In addition, syntax highlighting and indenting are quite different, for
example. Consequently, becoming a maintainer of a "mode" would involve
an a steeper learning curve than becoming a maintainer of one of the pieces.
Perhaps I misunderstand your proposal; if there's to be several people
maintaining a mode, then that's basically what we have now. If you're
talking about the organization of the files (syntax/, indent/,
ftplugin/ vs. mode/language/[with syntax, indent, ftplugins
therein] I don't see any real benefit. Not all languages currently have
indent or ftplugin portions (syntax highlighting is probably the biggest
of the three portions), so one can't require modes without a lot of
additional contributions.
Regards,
Chip Campbell
krischik
>
> <snip>
>
> > My proposal (if you have not guessed already) is to merge more
> > separate plug ins into modes.
>
> We do something similar withhttp://vim-ruby.rubyforge.org/which
> distributes all of the 'official' Ruby related runtime files in a
> single package.
>
> > What do you think about the idea?
>
> In general I think it's a good idea but what exactly are you
> proposing? How would this work in practice?
Well, two fold:
1) Development need to be coordinated - not nessesary by just one
person but a team. But a team it would need to be. Sourcefore springs
to mind - question would be: lot's of small projects or one big
project with lot's of sub-projects.
2) Distribution need to be coordinated - vimball, tar, zip. I use
vimball as it will work on any platform where vim runs. And a new
category on vim.org might be helpfull. Currently vim.org is supports
only "color", "ftplugin", "game", "indent", "syntax", "utility".
Martin
krischik
On Aug 28, 2:10 pm, Charles E Campbell Jr <drc...@campbellfamily.biz>
wrote:
> krischik wrote:
> >My proposal (if you have not guessed already) is to merge more
> >separate plug ins into modes. What do you think about the idea?
>
> Well, it sounds like a "mode" is a combination of three plugins (syntax,
> indent, ftplugin, ), and you want one person to maintain them all for a
> specific language.
Not quite. It would be a combinations of up to 7 plugins (syntax,
indent, ftplugin, ftdetect, completion, compiler, autoload) and a doc
file. I would consider "autoload" and "doc" the compulsory part -
otherwise there would be no point in a coordinated effeort.
I suggest you have a look at autoload/ada.vim and doc/ada.doc which
comes with your vim 7.1 distribution.
> as you did for clearcase.
I did not do clearcase - i did Ada ;-).
> In the case of some of the
> syntax highlighting plugins I'm maintaining (tex, vim, sh, lisp, csh),
> that would either mean I give up maintaining the syntax highlighting
> plugins I wrote or taking on a bunch of other folk's plugins. I can't
> say I'm enthusiastic about taking on maintenance for other's plugins (I
> have quite enough maintaining already!).
No - one could also form a team.
> In addition, syntax highlighting and indenting are quite different, for
> example. Consequently, becoming a maintainer of a "mode" would involve
> an a steeper learning curve than becoming a maintainer of one of the pieces.
Yes, but not a steep as you think: If you form a team then the common
part would be "autoload" and "doc" and the additional skills needed
would be "how to write autoload functions, variables, constants" and
"how to write doc files".
> Perhaps I misunderstand your proposal; if there's to be several people
> maintaining a mode, then that's basically what we have now. If you're
> talking about the organization of the files (syntax/, indent/,
> ftplugin/ vs. mode/language/[with syntax, indent, ftplugins
> therein] I don't see any real benefit. Not all languages currently have
> indent or ftplugin portions (syntax highlighting is probably the biggest
> of the three portions), so one can't require modes without a lot of
> additional contributions.
I see now that I should have stressed the power of "autoload" in my
original post - I thought you all know by now what it is about. For
those you don't:
Autoload allows functions, variables, constants, objects and classes
to be loaded only when they are needed.
For examle: if (in Vim 7.1) you type
:echo g:ada#Keywords[1]
then Vim will notice that there is no g:ada#Keywords defined. Because
of this Vim automaticly load "autoload/ada.vim" - which will defined
the referenced variable and the print out:
{'word': 'else', 'menu': 'keyword', 'info': 'Ada keyword.', 'kind':
'k', 'icase': 1}
See what I mean?
Martin
Martin
Tony Mechelynck
>
>
> On Aug 28, 2:10 pm, Charles E Campbell Jr <drc...@campbellfamily.biz>
> wrote:
>> krischik wrote:
>>> My proposal (if you have not guessed already) is to merge more
>>> separate plug ins into modes. What do you think about the idea?
>> Well, it sounds like a "mode" is a combination of three plugins (syntax,
>> indent, ftplugin, ), and you want one person to maintain them all for a
>> specific language.
>
> Not quite. It would be a combinations of up to 7 plugins (syntax,
> indent, ftplugin, ftdetect, completion, compiler, autoload) and a doc
> file. I would consider "autoload" and "doc" the compulsory part -
> otherwise there would be no point in a coordinated effeort.
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.
Best regards,
Tony.
--
A novel approach is to remove all power from the system, which
removes most system overhead so that resources can be fully devoted to
doing nothing. Benchmarks on this technique are promising; tremendous
amounts of nothing can be produced in this manner. Certain hardware
limitations can limit the speed of this method, especially in the
larger systems which require a more involved & less efficient
power-down sequence.
An alternate approach is to pull the main breaker for the
building, which seems to provide even more nothing, but in truth has
bugs in it, since it usually inhibits the systems which keep the beer
cool.
herm...@free.fr
krischik <kris...@users.sourceforge.net> wrote:
> On Aug 28, 2:10 pm, Charles E Campbell Jr <drc...@campbellfamily.biz> wrote:
> > krischik wrote:
> > >My proposal (if you have not guessed already) is to merge more
> > >separate plug ins into modes. What do you think about the idea?
> >
> > Well, it sounds like a "mode" is a combination of three plugins
> > (syntax, indent, ftplugin, ), and you want one person to maintain
> > them all for a specific language.
>
> Not quite. It would be a combinations of up to 7 plugins (syntax,
> indent, ftplugin, ftdetect, completion, compiler, autoload) and a doc
> file. I would consider "autoload" and "doc" the compulsory part -
> otherwise there would be no point in a coordinated effort.
This is not always applicable (/do-able?)
compiler plugins are a bit independent of the filetype.
For instance, there are several C&C++ compilers that produce errors in
different formats. And I'm quite sure this is also true with other
languages. Moreover, sometimes we must filter the outputs because of
intermediary tools that have nothing to do with the language (-> Cygwin,
ant, ...)
syntax+indent+fold+completion plugins can, and should, be distributed
with vim.
Regarding ftplugins, well a minimum is to be distributed with vim as it
already is today.
However, having a _complex_ suite, for a given filetype, that also
contains the files that should be distributed with vim does not sounds
like a good idea.
Also, distributing a complex suite with vim does not sound like a good
idea either -- sometimes there exist several alternative suites
maintained by different "competitors", and they may not always be
compatible.
NB: By complex suite, I mean suites like the one I'm maintaining for
C&C++ (-> http://hermitte.free.fr/vim/ressources/lh-cpp.tar.gz)
Otherwise, I think your proposal of coordinating efforts is a good thing.
When I wrote a PCGen syntax+completion plugin, I did mix different
things in a same file (syntax file) in order to avoid redundant
definitions. autoload plugins may indeed be a better way to factorized
common code and definitions.
(-> http://hermitte.free.fr/vim/ressources/vimfiles/syntax/pcgen.vim)
[...]
> I see now that I should have stressed the power of "autoload" in my
> original post - I thought you all know by now what it is about. For
> those you don't:
Lately, I've been thinking about writing a new tip about "How to write a
Vim(L) Library". Unfortunately I miss the time to do so. :-(
Regarding your particular example, what is nice in autoload plugins is not just
the lazy/delayed loading of the script (as in all cases, you'll need to load it
either way when entering an Ada buffer ; a simple "runtime macros/ada.vim" in
all your scripts would have been enough as everything is immediatelly needed in
syntax plugins), but the scoping.
PS: As "mode" already means something in Vim context, I do not really
like this new use of the term.
--
Luc Hermitte
http://hermitte.free.fr/vim/
herm...@free.fr
> 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,
krischik
> compiler plugins are a bit independent of the filetype.
> For instance, there are several C&C++ compilers that produce errors in
> different formats. And I'm quite sure this is also true with other
> languages. Moreover, sometimes we must filter the outputs because of
> intermediary tools that have nothing to do with the language (-> Cygwin,
> ant, ...)
Less independed then you think. The Ada-Mode comes with two compiler
plugin (GNAT and DecAda) and depending on the setting of
g:ada_default_compiler one of them is loaded when an Ada source is
edited.
I see this an an improvement to the default behaviour where by default
no compiler plugin is loaded and you have to do it all yourself by
automcd magic in your .vimrc. After all you don't want to load a
compiler setup when you are working on unrelated files.
> syntax+indent+fold+completion plugins can, and should, be distributed
> with vim.
The Ada-Mode too is distributed with Vim. There is just one catch: The
runtime is not patched. If working with a specific laguage make 50+%
of your time you want the newest version with a minimum of hassle.
BTW: Edit a *.adb file and you will quickly discover a nasty bug which
happens when not all the appropiate g:ada_* variables are
initialized. :-( - This bus is fixed in the version you can download
from vim.org :-) .
> Regarding ftplugins, well a minimum is to be distributed with vim as it
> already is today.
But they still need to be maintained and improved.
> However, having a _complex_ suite, for a given filetype, that also
> contains the files that should be distributed with vim does not sounds
> like a good idea.
> Also, distributing a complex suite with vim does not sound like a good
> idea either -- sometimes there exist several alternative suites
> maintained by different "competitors", and they may not always be
> compatible.
>
> NB: By complex suite, I mean suites like the one I'm maintaining for
> C&C++ (->http://hermitte.free.fr/vim/ressources/lh-cpp.tar.gz)
Ok, the Ada-Mode is not quite as large - it is certainly not to big to
not to be part of the main distribution.
> Regarding your particular example, what is nice in autoload plugins is not just
> the lazy/delayed loading of the script (as in all cases, you'll need to load it
> either way when entering an Ada buffer ; a simple "runtime macros/ada.vim" in
> all your scripts would have been enough as everything is immediatelly needed in
> syntax plugins), but the scoping.
Yes, you are right on both accounts.
> PS: As "mode" already means something in Vim context, I do not really
> like this new use of the term.
Got an alternative name?
Martin
Richard Hartmann
Environment? Framework? Package? Helper?
Richard
krischik
wrote:
> On 31/08/07, krischik <krisc...@users.sourceforge.net> wrote:
>
> > On Aug 30, 2:46 pm, hermi...@free.fr wrote:
> > > PS: As "mode" already means something in Vim context, I do not really
> > > like this new use of the term.
>
> > Got an alternative name?
>
> Environment? Framework? Package? Helper?
I like "Framework" best.
Martin
Edward L. Fox
Why not use some geeky expression to make the name *unique*?
I suggest calling it "superior".
>
> Martin
>
>
> >
>
herm...@free.fr
krischik <kris...@users.sourceforge.net> wrote:
> On Aug 30, 2:46 pm, hermi...@free.fr wrote:
>
> > compiler plugins are a bit independent of the filetype.
> > For instance, there are several C&C++ compilers that produce errors in
> > different formats. And I'm quite sure this is also true with other
> > languages. Moreover, sometimes we must filter the outputs because of
> > intermediary tools that have nothing to do with the language (-> Cygwin,
> > ant, ...)
>
> Less independed then you think. The Ada-Mode comes with two compiler
> plugin (GNAT and DecAda) and depending on the setting of
> g:ada_default_compiler one of them is loaded when an Ada source is
> edited.
> I see this an an improvement to the default behaviour where by default
> no compiler plugin is loaded and you have to do it all yourself by
> automcd magic in your .vimrc. After all you don't want to load a
> compiler setup when you are working on unrelated files.
I use some automagic commands (and two plugins of mine) to load compiler plugins
according to the project (defined as directories on the disk) I'm working on.
> > syntax+indent+fold+completion plugins can, and should, be distributed
> > with vim.
>
> [...]
> > Regarding ftplugins, well a minimum is to be distributed with vim as it
> > already is today.
>
> But they still need to be maintained and improved.
Indeed. Just out of curiousity, how often do they change between two versions of
Vim ?
> > PS: As "mode" already means something in Vim context, I do not really
> > like this new use of the term.
>
> Got an alternative name?
I wish I had :-(
It would be something with "filetype" I guess.
--
Luc Hermitte
Michael Henry
The TextMate editor on OS X uses the term "bundle" for this kind of
thing. Apple defines a bundle[1] as "a directory in the file system
that contains executable code and related resources". I don't know if
it would be confusing to OS X developers to reuse the term "bundle" for
your proposed "Mode" concept in Vim; but then again, Mac users are in
the minority (especially Mac developers).
Other possibilities, in no particular order:
- filetype kit
- filetype package
- filetype pack
- filetype suite
I've been using the following sentence in my head to see how these sound:
"Download and install the ADA (blank)."
Michael Henry
[1]: See "Bundles" section on this page:
http://developer.apple.com/documentation/Porting/Conceptual/win32porting/Articles/intern.html
Richard Hartmann
> - filetype suite
I think filetype suite or filetype suite or, even better,
filetype bundle have a nice ring to them.
'Perl filetype bundle' - I like that.
The other thing is environment..
'[VIM] Perl environment' - that also tells you at a glance what it is
about
Richard
krischik
> Indeed. Just out of curiousity, how often do they change between two versions of
> Vim ?
You can have a look for yourself:
Before I switched to a "Mode":
http://www.vim.org/scripts/script.php?script_id=1353
http://www.vim.org/scripts/script.php?script_id=1548
http://www.vim.org/scripts/script.php?script_id=1547
http://www.vim.org/scripts/script.php?script_id=1554
http://www.vim.org/scripts/script.php?script_id=1565
And later the same 5 plugins as one package:
http://www.vim.org/scripts/script.php?script_id=1609
Especialy when 7.0 with all the new features came out I did 1 to 3
releases per month. Now it is quiter again - but I did a bugfix since
7.1.
Martin
Andy Wokula
Bundle?
--
Andy
Andy Wokula
Oops, this was one click too fast, missed the rest of the thread.
--
Andy