Added support for spell checking in runtime/syntax/ocaml.vim

188 views
Skip to first unread message

Dominique Pellé

unread,
May 11, 2012, 3:02:39 PM5/11/12
to vim_dev, Markus Mottl
Hi

Attached patch adds @Spell to the runtime/syntax/ocaml.vim file
so that Vim only highlights spelling mistakes in comments and
strings when editing an ocaml source file with those settings:

:syntax on
:set spell

Regards
-- Dominique
fix-spell-ocaml.vim.patch

Charles Campbell

unread,
May 11, 2012, 3:57:04 PM5/11/12
to vim...@googlegroups.com
Dominique: did you contact the syntax file maintainers? (ditto for the
other two syntax file changes).

Regards,
Chip Campbell

Dominique Pellé

unread,
May 11, 2012, 4:02:34 PM5/11/12
to vim...@googlegroups.com
Charles Campbell <Charles.E...@nasa.gov> wrote:
Yes. Maintainers were in CC of the emails. But perhaps I should write
to the maintainers only to avoid sending too many emails to vim_dev
(still more of those simple patches to come...)

Regards
-- Dominique

John Beckett

unread,
May 11, 2012, 8:18:09 PM5/11/12
to vim...@googlegroups.com
Dominique Pellé wrote:
> Yes. Maintainers were in CC of the emails. But perhaps I
> should write to the maintainers only to avoid sending too many
> emails to vim_dev (still more of those simple patches to
> come...)

There is no good way to do this except to email the maintainers
only ... wait, try again ... repeat. If get a positive response,
good. Otherwise, find a volunteer to take over maintenance!

That's too much work for what you are doing, but Bram cannot
take patches like these because the maintainer might later send
an update to Bram, but the maintainer failed to receive, or
failed to process, your email. So the later update could easily
remove your patch.

John

Dominique Pellé

unread,
May 12, 2012, 12:27:33 AM5/12/12
to vim...@googlegroups.com
I've started to send patches to maintainers. I'll wait for responses.

Some of the emails of maintainers already bounce, at least
for syntax/{bc,expect,vhdl}.vim.

Unless current maintainer sends messages, I volunteer to
maintain bc.vim (last change was in 2001).

I have not used expect or vhdl in years so I'd rather let
someone else volunteer to maintain them.

Regards
-- Dominique

Thilo Six

unread,
May 12, 2012, 8:32:12 AM5/12/12
to vim...@vim.org
Hello John,


Excerpt from John Beckett:
That is exactlx what i think about the current practice, too.
Really i think instead of that single-point-of-failure modell of maintenance we
should move the a team maintenance of runtimefiles.
Unless that changes it is nearly impossible to get archive wide
features/policies applied.

>
> John
>

--
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F


Benjamin R. Haskell

unread,
May 13, 2012, 4:57:45 PM5/13/12
to vim...@googlegroups.com
On Sat, 12 May 2012, Thilo Six wrote:

> Excerpt from John Beckett:
>
>> Dominique Pellé wrote:
>>> Yes. Maintainers were in CC of the emails. But perhaps I should
>>> write to the maintainers only to avoid sending too many emails to
>>> vim_dev (still more of those simple patches to come...)
>>
>> There is no good way to do this except to email the maintainers only
>> ... wait, try again ... repeat. If get a positive response, good.
>> Otherwise, find a volunteer to take over maintenance!
>>
>> That's too much work for what you are doing, but Bram cannot take
>> patches like these because the maintainer might later send an update
>> to Bram, but the maintainer failed to receive, or failed to process,
>> your email. So the later update could easily remove your patch.
>
> That is exactlx what i think about the current practice, too. Really
> i think instead of that single-point-of-failure modell of maintenance
> we should move the a team maintenance of runtimefiles. Unless that
> changes it is nearly impossible to get archive wide features/policies
> applied.

I concur completely that a team of runtime file maintainers sounds
better. Back in January, I started composing an email wondering whether
having maintainers still made sense as a development model.
(Personally, I also find it very odd that even after switching to
Mercurial there are still hundreds of individual patch-files that can be
obtained via FTP, but that's probably a much broader discussion.) In
addition to the issues with maintainership mentioned so far:

- Maintainer might not be responsive, creating more work for Bram and/or
the maintainer later

- Maintainer can't make Vim-wide changes (like the '&cpo' changes from
earlier this year)

My main concerns are that:

- (it seems) Many maintainers are never really all-that committed.

Probably similar to the above concerns, but it makes perfect sense.
Over the past nine years, the main programming language I myself use on
a daily basis has gone from Perl to C# to PHP and now to Ruby. It's
hard to find someone to be a long-term maintainer for {Language X} where
that user is also well-versed enough in Vim to keep the syntax
well-maintained.

- Having a maintainer makes bugs last longer, especially for minor bugs.

Since even minor changes have to go through a maintainer, (it seems)
that changes don't immediately get sent back up to Bram. Often versions
seem to linger until there are enough minor updates that the maintainer.


Just for some data points, at the time I was writing the email in
January (which I never sent), I was able to very quickly find four
instances where having a maintainer made things more difficult:

Date | Subject:

2012-01-31 | ruby.vim does not work with greater than rubygems 1.7
Patch was mailed to maintainer, possibly didn't get back to Bram.

2012-01-17 | [patch] indent/java.vim: the line after @Override should not indent
Java maintainer has resigned.

2012-01-16 | spellcheck in mail: Subject header key is incorrectly underlined
Lech Lorens reported to maintainer long ago, update didn't get to Bram.

2012-01-08 | [patch] vim: runtime/syntax/jam.vim
Email bounced trying to send to maintainer, so sent patch to list.

--
Best,
Ben

Thilo Six

unread,
May 14, 2012, 1:19:04 PM5/14/12
to vim...@vim.org
Hello Benjamin,


Excerpt from Benjamin R. Haskell:

-- <snip> --
> I concur completely that a team of runtime file maintainers sounds
> better. Back in January, I started composing an email wondering whether
> having maintainers still made sense as a development model.
> (Personally, I also find it very odd that even after switching to
> Mercurial there are still hundreds of individual patch-files that can be
> obtained via FTP, but that's probably a much broader discussion.) In
> addition to the issues with maintainership mentioned so far:
>
> - Maintainer might not be responsive, creating more work for Bram and/or
> the maintainer later

..or a random patch submitter.
confirmed.

> - Maintainer can't make Vim-wide changes (like the '&cpo' changes from
> earlier this year)

confirmed.

>
> My main concerns are that:
>
> - (it seems) Many maintainers are never really all-that committed.

IIRC a maintainer has committed himself to be reachable via email 3 years after
his last change. (I must have read that in vim help somewhere, but need to seek
that out again first where exactly that was).

...but

$ recgrep -c "by Thilo Six" . | grepinvert "0$" | wc -l
28

basically all of those files have been changed last time by their original
maintainer a decade ago!

> Probably similar to the above concerns, but it makes perfect sense.
> Over the past nine years, the main programming language I myself use on
> a daily basis has gone from Perl to C# to PHP and now to Ruby. It's
> hard to find someone to be a long-term maintainer for {Language X} where
> that user is also well-versed enough in Vim to keep the syntax
> well-maintained.
>
> - Having a maintainer makes bugs last longer, especially for minor bugs.
>
> Since even minor changes have to go through a maintainer, (it seems)
> that changes don't immediately get sent back up to Bram. Often versions
> seem to linger until there are enough minor updates that the maintainer.

I know currently patches go lost!

> Just for some data points, at the time I was writing the email in
> January (which I never sent), I was able to very quickly find four
> instances where having a maintainer made things more difficult:
>
> Date | Subject:
>
> 2012-01-31 | ruby.vim does not work with greater than rubygems 1.7
> Patch was mailed to maintainer, possibly didn't get back to Bram.
>
> 2012-01-17 | [patch] indent/java.vim: the line after @Override should not indent
> Java maintainer has resigned.
>
> 2012-01-16 | spellcheck in mail: Subject header key is incorrectly underlined
> Lech Lorens reported to maintainer long ago, update didn't get to Bram.
>
> 2012-01-08 | [patch] vim: runtime/syntax/jam.vim
> Email bounced trying to send to maintainer, so sent patch to list.


--

Thilo Six

unread,
May 14, 2012, 1:34:03 PM5/14/12
to vim...@vim.org

-- <snip> --
> IIRC a maintainer has committed himself to be reachable via email 3 years after
> his last change. (I must have read that in vim help somewhere, but need to seek
> that out again first where exactly that was).
>

This is a good read:
:h develop.txt

though it does no contain that portion i am seeking
-- <snip> --

Dominique Pellé

unread,
May 14, 2012, 2:11:30 PM5/14/12
to vim...@googlegroups.com
Benjamin R. Haskell <v...@benizi.com> wrote:

[...]
> On Sat, 12 May 2012, Thilo Six wrote:
[...]
>> That is exactlx what i think about the current practice, too.  Really i
>> think instead of that single-point-of-failure modell of maintenance we
>> should move the a team maintenance of runtimefiles.  Unless that changes it
>> is nearly impossible to get archive wide features/policies applied.
>
>
> I concur completely that a team of runtime file maintainers sounds better.

Yes, a team of runtime file maintainers sounds good to me,
at least for files that have not been touched by the maintainer
in the last x years.

Some statistics: I've contacted the maintainers of 15 syntax files
this weekend to add spelling checker support. The stats so far are:

- 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
- 6 emails without response so far (but it's fair to wait a bit more);
- 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.

I'll send the proposed patch to Bram after I wait a bit further.

Regards
-- Dominique

Thilo Six

unread,
May 14, 2012, 2:22:30 PM5/14/12
to vim...@vim.org
Hello Dominique,


Excerpt from Dominique Pell�:

-- <snip> --
> Some statistics: I've contacted the maintainers of 15 syntax files
> this weekend to add spelling checker support. The stats so far are:
>
> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> - 6 emails without response so far (but it's fair to wait a bit more);
> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.


in short 4 to 11.

Some months later that will change to somewhat 10 to 5. piriod.
Sad but true... and nothing else matters!

>
> I'll send the proposed patch to Bram after I wait a bit further.
>
> Regards
> -- Dominique
>

Thomas Köhler

unread,
May 14, 2012, 2:39:46 PM5/14/12
to vim...@googlegroups.com
Hi all,

Dominique Pellé wrote:
> Benjamin R. Haskell <v...@benizi.com> wrote:
> [...]
> > On Sat, 12 May 2012, Thilo Six wrote:
> [...]
> >> That is exactlx what i think about the current practice, too.  Really i
> >> think instead of that single-point-of-failure modell of maintenance we
> >> should move the a team maintenance of runtimefiles.  Unless that changes it
> >> is nearly impossible to get archive wide features/policies applied.

You may be right here, but there's a reason for the current
model...

> > I concur completely that a team of runtime file maintainers sounds better.

And it would help people like me that used to maintain some
runtime files in the past and now are stuck maintaining something
they don't use any longer.
For me, that would be the syntax files for uil (motif user
interface language) and prolog, both of which I used to use at
university. But I left university more than 10 years ago, so I'm
stuck with maintaining something I don't use any longer myself.

But of course, there once was a reason for the current model,
which is "let people maintain the stuff who know what they are
doing" in the sense that people started maintain runtime files
when they were using the stuff by themselves. Unfortunately, the
only thing I keep using myself today is the koehler.vim
colorscheme :-)

If a group of maintainers was to take over the runtime files, I
would be glad to hand over the uil and prolog syntax files to
someone who is willing to dedicate the time and effort needed,
while I really would keep maintaining the koehler.vim colorscheme
myself :-)

> Yes, a team of runtime file maintainers sounds good to me,
> at least for files that have not been touched by the maintainer
> in the last x years.
>
> Some statistics: I've contacted the maintainers of 15 syntax files
> this weekend to add spelling checker support. The stats so far are:
>
> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> - 6 emails without response so far (but it's fair to wait a bit more);

That should now at least be 5:5 :-)
It's always a good idea to give people a few days time to reply,
especially for their private email which they might not read for
a few days. When I am on vacation, it is possible that I don't
read my mail for two or three weeks - because my vacation tends
to be a no-internet-for-a-while time :)

> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.
>
> I'll send the proposed patch to Bram after I wait a bit further.

That's a good approach for the fallback in any case.

> Regards
> -- Dominique

Ciao,
Thomas

--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!
signature.asc

Thilo Six

unread,
May 14, 2012, 4:13:44 PM5/14/12
to vim...@vim.org
Hello Thomas,

I answer on list.


Excerpt from Thomas K�hler:

-- <snip> --
> And it would help people like me that used to maintain some
> runtime files in the past and now are stuck maintaining something
> they don't use any longer.

I think that is exactly the meaning of team maintenance.
I commit my myself NOW for bringing some runtimefile forward BUT do NOT commit
myself the next decade to do the same!

> For me, that would be the syntax files for uil (motif user
> interface language) and prolog,

Personally i saw some (some more) patches gone lost.

> both of which I used to use at
> university. But I left university more than 10 years ago, so I'm
> stuck with maintaining something I don't use any longer myself.

see above.

> But of course, there once was a reason for the current model,
> which is "let people maintain the stuff who know what they are
> doing"

That exactly will not be broke by team maintenance!


> in the sense that people started maintain runtime files
> when they were using the stuff by themselves. Unfortunately, the
> only thing I keep using myself today is the koehler.vim
> colorscheme :-)

;)

> If a group of maintainers was to take over the runtime files, I
> would be glad to hand over the uil and prolog syntax files to
> someone who is willing to dedicate the time and effort needed,
> while I really would keep maintaining the koehler.vim colorscheme
> myself :-)

There will be problems! No matter what.
But the point is currently there is no one who is willing to take over some
runtimefiles because currently there is no one willing to dedicate time to it.
My personal hope is that team maintenance will neglect the availability of
individuals compared to the availability of a team member.

>> Yes, a team of runtime file maintainers sounds good to me,
>> at least for files that have not been touched by the maintainer
>> in the last x years.
>>
>> Some statistics: I've contacted the maintainers of 15 syntax files
>> this weekend to add spelling checker support. The stats so far are:
>>
>> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
>> - 6 emails without response so far (but it's fair to wait a bit more);
>
> That should now at least be 5:5 :-)
> It's always a good idea to give people a few days time to reply,
> especially for their private email which they might not read for
> a few days. When I am on vacation, it is possible that I don't
> read my mail for two or three weeks - because my vacation tends
> to be a no-internet-for-a-while time :)

Personal i gave people now more than 6 months to respond. Without success!
How long should we wait until we expect someone to be MIA?

Personal i think Vim runtimefiles is like Debian without the so called MIA
proses and without Debian policy!

Really Debian had the smae struggles in the past why not learn from their
experience they had in the past?

I hate the not invented here syndrome not only for:
http://koeln.ccc.de/prozesse/writing/artikel/hacker-howto-esr.xml
which is german but it says at top that its english version is at:
http://catb.org/~esr/faqs/hacker-howto.html

but also because of Vim is precision to the byte. It is striving for perfection.

>> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.
>>
>> I'll send the proposed patch to Bram after I wait a bit further.
>
> That's a good approach for the fallback in any case.
>
>> Regards
>> -- Dominique
>
> Ciao,
> Thomas
>

--

Thomas Köhler

unread,
May 15, 2012, 2:49:40 AM5/15/12
to vim...@vim.org
Hi Thilo,

Thilo Six wrote:
> Excerpt from Thomas Köhler:
>
> -- <snip> --
> > And it would help people like me that used to maintain some
> > runtime files in the past and now are stuck maintaining something
> > they don't use any longer.
> I think that is exactly the meaning of team maintenance.
> I commit my myself NOW for bringing some runtimefile forward BUT do NOT commit
> myself the next decade to do the same!

Well, that's fine, as long as someone else picks up the work
later.

> > For me, that would be the syntax files for uil (motif user
> > interface language) and prolog,
> Personally i saw some (some more) patches gone lost.

To my syntax files?
Well, it's possible I didn't see the mails, as I have to use a
spam filter to be able to follow my private email at all, and you
can never rule out false positives, but if you can tell me when
there were emails that belong to one of my syntax files, I will
have a look in my mail archives.

[...]
> > But of course, there once was a reason for the current model,
> > which is "let people maintain the stuff who know what they are
> > doing"
> That exactly will not be broke by team maintenance!

Well, there might be a problem anyway. I expect uil is no longer
used very much, and prolog is still used, but I expect usage to
be highest at universities. It might be that none of the vim
users that edit uil or prolog files today are fluent enough in
vim's scripting language to be able to maintain a syntax file,
but they are glad there is a syntax file at all.

My point is: team maintenance only works well if there are at
least two people that know enough about *each* file type to be
able to actually maintain the file. That might not be true for
all of the lots of file types supported by vim right now.

> > If a group of maintainers was to take over the runtime files, I
> > would be glad to hand over the uil and prolog syntax files to
> > someone who is willing to dedicate the time and effort needed,
> > while I really would keep maintaining the koehler.vim colorscheme
> > myself :-)
>
> There will be problems! No matter what.
> But the point is currently there is no one who is willing to take over some
> runtimefiles because currently there is no one willing to dedicate time to it.
> My personal hope is that team maintenance will neglect the availability of
> individuals compared to the availability of a team member.

The problem is clear: If no one is willing to dedicate time
maintaining runtime files, you will never end up having a team of
maintainers...

> >> Yes, a team of runtime file maintainers sounds good to me,
> >> at least for files that have not been touched by the maintainer
> >> in the last x years.

BTW, some files might not be changed because there is not much need.
I last changed uil.vim and prolog.vim in 2009 to support some new
feature available in vim (and uil.vim yesterday due to
Dominique's patch for @Spell support), and before that, I think I
changed them somewhen back in 2004 or so (I would have to check
my mail archive, as I don't have the syntax files in version
control yet).

> >> Some statistics: I've contacted the maintainers of 15 syntax files
> >> this weekend to add spelling checker support. The stats so far are:
> >>
> >> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> >> - 6 emails without response so far (but it's fair to wait a bit more);
> >
> > That should now at least be 5:5 :-)
> > It's always a good idea to give people a few days time to reply,
> > especially for their private email which they might not read for
> > a few days. When I am on vacation, it is possible that I don't
> > read my mail for two or three weeks - because my vacation tends
> > to be a no-internet-for-a-while time :)
>
> Personal i gave people now more than 6 months to respond. Without success!
> How long should we wait until we expect someone to be MIA?

I'd say 6 months is too long, but please try several times, as
your first mail might have ended up in some spam filter. But if
you don't get a response after two or three months, the runtime
file should be considered orphaned IMHO. I think this point
should be discussed.

> Personal i think Vim runtimefiles is like Debian without the so called MIA
> proses and without Debian policy!
>
> Really Debian had the smae struggles in the past why not learn from their
> experience they had in the past?

There might be some more debian maintainers out there than there
are vim runtime file maintainers, plus there are always some
debian packages being orphaned or completely removed from debian.
Maybe it should be discussed how to handle orphaned runtime files
anyway.
But I don't think we can send orphaned runtime files to Kibaale :)

> I hate the not invented here syndrome not only for:
> http://koeln.ccc.de/prozesse/writing/artikel/hacker-howto-esr.xml
> which is german but it says at top that its english version is at:
> http://catb.org/~esr/faqs/hacker-howto.html
>
> but also because of Vim is precision to the byte. It is striving for perfection.

Perfection will never be reached. There is always something one
could do better :-)
signature.asc

Benjamin R. Haskell

unread,
May 15, 2012, 10:08:35 AM5/15/12
to vim...@googlegroups.com, vim...@vim.org
On Tue, 15 May 2012, Thomas Köhler wrote:

> Hi Thilo,
>
> Thilo Six wrote:
>> Excerpt from Thomas Köhler:
>>
>> -- <snip> --
>>> And it would help people like me that used to maintain some runtime
>>> files in the past and now are stuck maintaining something they don't
>>> use any longer.
>> I think that is exactly the meaning of team maintenance. I commit my
>> myself NOW for bringing some runtimefile forward BUT do NOT commit
>> myself the next decade to do the same!
>
> Well, that's fine, as long as someone else picks up the work later.
>
>>> For me, that would be the syntax files for uil (motif user interface
>>> language) and prolog,
>> Personally i saw some (some more) patches gone lost.
>
> To my syntax files?

(I'm fairly certain Thilo meant that some have gone lost in general, not
for your specific syntax files.)


> [...]

>>> But of course, there once was a reason for the current model, which
>>> is "let people maintain the stuff who know what they are doing"
>> That exactly will not be broke by team maintenance!
>
> Well, there might be a problem anyway. I expect uil is no longer used
> very much, and prolog is still used, but I expect usage to be highest
> at universities. It might be that none of the vim users that edit uil
> or prolog files today are fluent enough in vim's scripting language to
> be able to maintain a syntax file, but they are glad there is a syntax
> file at all.
>
> My point is: team maintenance only works well if there are at least
> two people that know enough about *each* file type to be able to
> actually maintain the file. That might not be true for all of the lots
> of file types supported by vim right now.

I think you're misinterpreting what "team maintenance" would mean. It
wouldn't be a team per language, but rather a single team to handle
changes (maintenance) to all syntax files. (Which doesn't preclude
active maintainers from continuing to actively maintain their current
files.)

The hard part of supporting a given language in Vim is the first step:
writing the syntax file in the first place. Once there's a
relatively-complete syntax file (and most of the syntax files included
in Vim are fairly mature), the changes to that syntax file are usually
straightforward.

If a language adds a new keyword, it can often go into the same syntax
group as the other keywords already handled. If a syntax file is
highlighting something incorrectly, there's often an easy fix that can
be applied. The problem is usually Vim-syntax-related rather than
something that requires knowledge of the language being highlighted.

Right now, maintainership requires:

A maintainer who knows about both {non-Vim-language X} and Vim.
A maintainer who knows about both {non-Vim-language Y} and Vim.
A maintainer who knows about both {non-Vim-language Z} and Vim.
...etc.

Very likely, each of those maintainers is a different person. Now,
expand it to 536 (the number of syntax files). As a rough cut, there
appear to be just under 300 distinct first-maintainer lines in those 536
files. -- Nikolai Weibull (with 69 files) skews the numbers quite a bit
(Nice work, 'now').

When a problem arises, even if the change is straightforward and doesn't
really require knowledge of the non-Vim language, the end user has to
contact a maintainer who is somewhat-likely to be absentee.

Team maintenance, on the other hand, would mean that there would be a
group of people who know about Vim and are able to make changes to an
arbitrary syntax file when the need arises. Someone interested in a
given language, with even a passing interest in Vim, can suggest a
change on the Vim list, and if it's straightforward, some member of the
team can go make the change. Even if the change is complicated, if
there's some other user of {language X} on the Vim list, it usually gets
worked out what change would need to be made.


>>> If a group of maintainers was to take over the runtime files, I
>>> would be glad to hand over the uil and prolog syntax files to
>>> someone who is willing to dedicate the time and effort needed, while
>>> I really would keep maintaining the koehler.vim colorscheme myself
>>> :-)
>>
>> There will be problems! No matter what. But the point is currently
>> there is no one who is willing to take over some runtimefiles because
>> currently there is no one willing to dedicate time to it. My
>> personal hope is that team maintenance will neglect the availability
>> of individuals compared to the availability of a team member.
>
> The problem is clear: If no one is willing to dedicate time
> maintaining runtime files, you will never end up having a team of
> maintainers...

It's not that "no one is willing to dedicate time maintaining runtime
files", it's that no one is willing to take over *some* runtime files.
(Java is a prominent current example.) There are plenty of regulars on
the Vim lists who seem to be willing to vet changes.

--
Best,
Ben

Thomas Köhler

unread,
May 15, 2012, 10:54:04 AM5/15/12
to vim...@googlegroups.com, vim...@vim.org
Hello Benjamin,

Benjamin R. Haskell wrote:
> On Tue, 15 May 2012, Thomas Köhler wrote:
> >Thilo Six wrote:
> >>Excerpt from Thomas Köhler:
[...]
> >>>But of course, there once was a reason for the current model, which
> >>>is "let people maintain the stuff who know what they are doing"
> >>That exactly will not be broke by team maintenance!
> >
> >Well, there might be a problem anyway. I expect uil is no longer used
> >very much, and prolog is still used, but I expect usage to be highest
> >at universities. It might be that none of the vim users that edit uil
> >or prolog files today are fluent enough in vim's scripting language to
> >be able to maintain a syntax file, but they are glad there is a syntax
> >file at all.
> >
> >My point is: team maintenance only works well if there are at least
> >two people that know enough about *each* file type to be able to
> >actually maintain the file. That might not be true for all of the lots
> >of file types supported by vim right now.
>
> I think you're misinterpreting what "team maintenance" would mean. It
> wouldn't be a team per language, but rather a single team to handle
> changes (maintenance) to all syntax files. (Which doesn't preclude
> active maintainers from continuing to actively maintain their current
> files.)

I didn't think of "a team per language", but "the team should
have two people who understand the language", as the goal seems
to have been "if one is not available, then another one should be
able to handle the issues".
OK, I understand your point. The problem then is: what happens if
the change is not so straight forward, but needed anyway (for
example if the specs of the language change).

> >The problem is clear: If no one is willing to dedicate time
> >maintaining runtime files, you will never end up having a team of
> >maintainers...
>
> It's not that "no one is willing to dedicate time maintaining runtime
> files", it's that no one is willing to take over *some* runtime files.
> (Java is a prominent current example.) There are plenty of regulars on
> the Vim lists who seem to be willing to vet changes.

OK, java might be a problem of its own, but then things end up in
"the maintainer team is willing to take over the following 325
syntax files, leaving another 536-325=211 syntax files in their
current status quo: ..." (numbers may vary, of course...)

But maybe that's better than the current situation, so orphaned
runtime files could automatically end up in the maintainer list
or something like that...
signature.asc

Ben Fritz

unread,
May 15, 2012, 11:39:21 AM5/15/12
to vim...@googlegroups.com
I like the idea of team maintenance of runtime files. I don't see why we shouldn't just do it for all the runtime files. Just set up a Bitbucket or Github clone (or another Google Code project, but I don't see a good way to relate it back to the main Vim repository, and clones made on the Google Code site can only have a single committer) and give all current runtime maintainers commit access. If a file has a listed maintainer, that person would by default be the person to make the change; but if they become unresponsive and the change is straightforward enough, the team could step in.

Thilo Six

unread,
May 15, 2012, 12:02:12 PM5/15/12
to vim...@vim.org
Hello Thomas and Benjamin,


Excerpt from Thomas K�hler:
-- <snip> --
>> I think you're misinterpreting what "team maintenance" would mean. It
>> wouldn't be a team per language, but rather a single team to handle
>> changes (maintenance) to all syntax files. (Which doesn't preclude
>> active maintainers from continuing to actively maintain their current
>> files.)
>
> I didn't think of "a team per language", but "the team should
> have two people who understand the language", as the goal seems
> to have been "if one is not available, then another one should be
> able to handle the issues".

When i think of this team i count each current maintainer as a member already.
The idea is to use a mailinglist where anyone who likes can subscribe (think of
vim-dev). All communication about runtimefiles happens openly. Not 99% via
private email where no one can learn from each other and reviewing changes is
left to Bram alone.

So basically the only change for now would then be this line:
" Maintainer: Thilo Six <T Dot Six At gmx dot de>

would change to
" Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>

Still i am the main-maintainer but not the only one. Questions, fixes, additions
would *NOT* go lost just because my mailprovider has changed, or because i lost
interest in it 4 years ago.

No one is anyone blocking to take care of their peeve pets.

I hope that makes my intention of this team a bight easier to understand.
Well what happens now in this case? Someone who is interested in it sit down and
patches it.

>>> The problem is clear: If no one is willing to dedicate time
>>> maintaining runtime files, you will never end up having a team of
>>> maintainers...
>>
>> It's not that "no one is willing to dedicate time maintaining runtime
>> files", it's that no one is willing to take over *some* runtime files.
>> (Java is a prominent current example.) There are plenty of regulars on
>> the Vim lists who seem to be willing to vet changes.
>
> OK, java might be a problem of its own, but then things end up in
> "the maintainer team is willing to take over the following 325
> syntax files, leaving another 536-325=211 syntax files in their
> current status quo: ..." (numbers may vary, of course...)
>
> But maybe that's better than the current situation, so orphaned
> runtime files could automatically end up in the maintainer list
> or something like that...

see above my example with the mailling list.

Gary Johnson

unread,
May 15, 2012, 12:25:05 PM5/15/12
to vim...@googlegroups.com
On 2012-05-15, Thilo Six wrote:

> When i think of this team i count each current maintainer as a member already.
> The idea is to use a mailinglist where anyone who likes can subscribe (think of
> vim-dev). All communication about runtimefiles happens openly. Not 99% via
> private email where no one can learn from each other and reviewing changes is
> left to Bram alone.
>
> So basically the only change for now would then be this line:
> " Maintainer: Thilo Six <T Dot Six At gmx dot de>
>
> would change to
> " Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>
>
> Still i am the main-maintainer but not the only one. Questions, fixes, additions
> would *NOT* go lost just because my mailprovider has changed, or because i lost
> interest in it 4 years ago.
>
> No one is anyone blocking to take care of their peeve pets.
>
> I hope that makes my intention of this team a bight easier to understand.

I like it.

Do you think there would be enough maintenance traffic to justify a
separate runtime-maintainers list or would vim-dev suffice?

Regards,
Gary

Christian Brabandt

unread,
May 15, 2012, 1:29:34 PM5/15/12
to vim...@googlegroups.com
On Di, 15 Mai 2012, Gary Johnson wrote:
> I like it.
>
> Do you think there would be enough maintenance traffic to justify a
> separate runtime-maintainers list or would vim-dev suffice?

+1

If the traffic isn't too big, I would prefer vim-dev list (since I am
already subscribed) so please add me to the list ;)

regards,
Christian

Thilo Six

unread,
May 15, 2012, 1:50:38 PM5/15/12
to vim...@vim.org, Bram Moolenaar
Hello Gary and Christian,


Excerpt from Christian Brabandt:
Seems we get it moving. Sounds great. :)

Personally i do not have any preference where this list is located. Regarding
using vim-dev i think we should also ask Bram what he thinks about that, cc'ed.

Bram what do you think putting runtimefiles under team maintenance and using
vim-dev for coordination of that group?

> regards,
> Christian

Ernie Rael

unread,
May 15, 2012, 4:32:42 PM5/15/12
to vim...@googlegroups.com
On 5/15/2012 9:02 AM, Thilo Six wrote:
>
> No one is anyone blocking to take care of their peeve pets.
I'd be hesitant to suggest that people "take care of their pet peeves".
Yes for real bugs or "infrastructure" features (like spell). But since
there is hopefully a main guy for each file, shouldn't random changes be
kept to a minimum?

Thomas Köhler

unread,
May 16, 2012, 2:14:00 AM5/16/12
to vim...@vim.org
Hello Thilo,

Thilo Six wrote:
> Hello Thomas and Benjamin,
> Excerpt from Thomas Köhler:
> -- <snip> --
> >> I think you're misinterpreting what "team maintenance" would mean. It
> >> wouldn't be a team per language, but rather a single team to handle
> >> changes (maintenance) to all syntax files. (Which doesn't preclude
> >> active maintainers from continuing to actively maintain their current
> >> files.)
> >
> > I didn't think of "a team per language", but "the team should
> > have two people who understand the language", as the goal seems
> > to have been "if one is not available, then another one should be
> > able to handle the issues".
>
> When i think of this team i count each current maintainer as a member already.
> The idea is to use a mailinglist where anyone who likes can subscribe (think of
> vim-dev). All communication about runtimefiles happens openly. Not 99% via
> private email where no one can learn from each other and reviewing changes is
> left to Bram alone.
>
> So basically the only change for now would then be this line:
> " Maintainer: Thilo Six <T Dot Six At gmx dot de>
>
> would change to
> " Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>
>
> Still i am the main-maintainer but not the only one. Questions, fixes, additions
> would *NOT* go lost just because my mailprovider has changed, or because i lost
> interest in it 4 years ago.
>
> No one is anyone blocking to take care of their peeve pets.
>
> I hope that makes my intention of this team a bight easier to understand.

OK, now things are clearer for me. That's basically a good idea,
but:
- URL would also need to change:
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
would need to become something different, for example
http://www.vim.org/runtimefiles/syntax/uil.vim
- all the vim runtime file maintainers would need to have
read/write access below http://www.vim.org/runtimefiles/ (or
whereever that is)

The reason is that if another maintainer changes a file, the file
also should be changed at the URL given in the file.

Of course there could be a git repository with all runtime files
included, and all maintainers just send patches to a group of git
maintainers, and the URL would point to where the central git
repository would show the file, which would put down the number
of people that need read/write access from a few hundred to just
a few. What do you think?
signature.asc

Benjamin R. Haskell

unread,
May 16, 2012, 2:32:31 AM5/16/12
to vim...@googlegroups.com
I took "pet peeves" to mean minor bugs that are annoying on a daily
basis, not random features. Personally, I think "random" (as in, minor)
changes should be maximized. The more items that go directly from bug
report to fixes in a short amount of time, the more pleasant it is to
use Vim.

--
Best,
Ben

Ben Fritz

unread,
May 16, 2012, 11:35:30 AM5/16/12
to vim...@googlegroups.com, vim...@vim.org
On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas Köhler wrote:
>
> OK, now things are clearer for me. That's basically a good idea,
> but:
> - URL would also need to change:
> http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
> would need to become something different, for example
> http://www.vim.org/runtimefiles/syntax/uil.vim
> - all the vim runtime file maintainers would need to have
> read/write access below http://www.vim.org/runtimefiles/ (or
> whereever that is)
>
> The reason is that if another maintainer changes a file, the file
> also should be changed at the URL given in the file.
>

Yes, agreed.

> Of course there could be a git repository with all runtime files
> included,

Or, how about just a clone of the main Vim repository? Often runtime file changes are related to changes in the Vim code. If we get going well enough we might even convince Bram to pull runtime file changes directly.

I think the "official" repository should be a Mercurial clone, because that's what Vim's official repository is, but there are extensions to both Hg and git which allow them to work on the other's repository or convert one to the other losslessly. So there could be secondary clones all over in git or Hg if desired.

> and all maintainers just send patches to a group of git
> maintainers, and the URL would point to where the central git
> repository would show the file, which would put down the number
> of people that need read/write access from a few hundred to just
> a few. What do you think?
>

I think I'd rather see it done with push/pull. If not everyone has push access (I don't see why that shouldn't be the goal) each maintainer could easily make their own clone and tell the main repo's maintainer(s) "please pull revXXXXXX from my repository at YYYY".

Periodically Bram could either pull from the runtime repository, or export the latest as a patch against the last merged version from the official repository.

Ben Fritz

unread,
May 16, 2012, 11:38:58 AM5/16/12
to vim...@googlegroups.com

Yes, I think that would be one of the main benefits of the team approach.

I think how to handle feature additions/big changes might depend on the "main" maintainer. Some might be OK with "big" changes being made, while others might want to reserve those for themselves.

One thing the maintainer might do is be the default reviewer for changes not done by him/herself. But if it hasn't happened in a timely fashion the team can step in.

Thilo Six

unread,
May 16, 2012, 1:56:13 PM5/16/12
to vim...@vim.org
Hello Ernie,


Excerpt from Ernie Rael:

-- <snip> --
> But since
> there is hopefully a main guy for each file, shouldn't random changes be
> kept to a minimum?

Well i can only speak for myself. Usually i very hardly try to be friendly. That
means the workflow of asking the maintainer for a change first would not change.
The difference would be that this question would happen openly on list instead
of pm.
The intention of team maintenance is to increase cooperation between maintainers
AND to reduce frustration because the person who has the last word is out of reach.

...and as already has been pointed out be me "hopefully a main guy for each
file" is just a hope not reality.
If you would wade through runtime you rather soon discover that fact.

Thilo Six

unread,
May 16, 2012, 2:17:20 PM5/16/12
to vim...@vim.org
Hi Thomas and Ben,


Excerpt from Ben Fritz:

> On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas K�hler wrote:
>>
>> OK, now things are clearer for me. That's basically a good idea,
>> but:
>> - URL would also need to change:
>> http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
>> would need to become something different, for example
>> http://www.vim.org/runtimefiles/syntax/uil.vim
>> - all the vim runtime file maintainers would need to have
>> read/write access below http://www.vim.org/runtimefiles/ (or
>> whereever that is)
>>
>> The reason is that if another maintainer changes a file, the file
>> also should be changed at the URL given in the file.
>>
>
> Yes, agreed.

*grin* we are already discussion implementation details. Seems like everyone
agrees this is a good way forward.

Well in my experience each active vim maintainer is rather knowledgeable *and*
friendly. I am sure if one tells an other: "Hey we need to change that url,
too". That asked person will do what he is asked for.
Same with a missing keyword, a suboptimal regex or what ever.
If we communicate we each other we will find a solution or an other. But the
situation that led to this thread was simply no communication, not even
technically possible.
As i said earlier there will be problems. Discuss them on list, think about
them, fix them.


>> Of course there could be a git repository with all runtime files
>> included,
>
> Or, how about just a clone of the main Vim repository? Often runtime file changes are related to changes in the Vim code. If we get going well enough we might even convince Bram to pull runtime file changes directly.
>
> I think the "official" repository should be a Mercurial clone, because that's what Vim's official repository is, but there are extensions to both Hg and git which allow them to work on the other's repository or convert one to the other losslessly. So there could be secondary clones all over in git or Hg if desired.
>
>> and all maintainers just send patches to a group of git
>> maintainers, and the URL would point to where the central git
>> repository would show the file, which would put down the number
>> of people that need read/write access from a few hundred to just
>> a few. What do you think?
>>
>
> I think I'd rather see it done with push/pull. If not everyone has push access (I don't see why that shouldn't be the goal) each maintainer could easily make their own clone and tell the main repo's maintainer(s) "please pull revXXXXXX from my repository at YYYY".
>
> Periodically Bram could either pull from the runtime repository, or export the latest as a patch against the last merged version from the official repository.

I thought about a repo, too. If we will have one i also prefer that it has an
interface to mercurial (probably even must have). No matter what that $VCS (or
%VCS% as some use here) will be.
Hopefully a nice fall-out would be that Bram can spend more time on Vim directly
rather then on runtimefiles. Lets see how that works out.

Ingo Karkat

unread,
May 16, 2012, 3:15:34 PM5/16/12
to vim...@googlegroups.com
On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:

> Or, how about just a clone of the main Vim repository? Often runtime
> file changes are related to changes in the Vim code.

Often? Vim has superb backward compatibility, and the thing that started this
thread is adding @Spell support, something which was introduced years ago with
Vim 7.0.

> If we get going well enough we might even convince Bram to pull
> runtime file changes directly.

I would like to see runtime files treated the same way as all other Vim sources.
Right now, no patches are published, and Bram just occasionally commits them to
the repo. I think Bram is already busy enough with the core sources, so the only
way for this to work without taxing him even more would be opening up the main
repo for a set of long-term, trusted deputies. (Which, assuming there are such
capable and willing volunteers, would be a good thing to avoid a potential
bottleneck, and could eventually offer a faster development speed - also for Vim
core. (Just take a look at the long todo list and patch queue.))

> I think I'd rather see it done with push/pull. If not everyone has
> push access (I don't see why that shouldn't be the goal) each
> maintainer could easily make their own clone and tell the main repo's
> maintainer(s) "please pull revXXXXXX from my repository at YYYY".

Ahem, if this depends on a main maintainer, we're back to where we are today: a
single person point of failure.

-- regards, ingo

Dominique Pellé

unread,
May 16, 2012, 3:42:48 PM5/16/12
to vim...@googlegroups.com
Ingo Karkat <sw...@ingo-karkat.de> wrote:

> I would like to see runtime files treated the same way as all other Vim sources.
> Right now, no patches are published, and Bram just occasionally commits them to
> the repo.

Aren't you using Mercurial? Runtime files are now updated quite
often in Mercurial. Here are the dates of the last 10 edits of
file runtime/doc/todo.txt in Mercurial for example:

$ hg log runtime/doc/todo.txt| grep '^date:' | head -10
date: Tue May 01 21:14:34 2012 +0200
date: Mon Apr 30 15:56:52 2012 +0200
date: Thu Apr 26 20:17:03 2012 +0200
date: Wed Apr 25 19:07:41 2012 +0200
date: Fri Apr 13 23:04:47 2012 +0200
date: Thu Apr 05 17:33:26 2012 +0200
date: Wed Mar 28 20:51:51 2012 +0200
date: Sun Mar 11 15:57:40 2012 +0100
date: Wed Feb 22 17:30:19 2012 +0100
date: Mon Feb 13 00:05:22 2012 +0100

Besides submitting patches to the vim runtime file, it would
also be good to suggest authors of good syntax files not
already present in the default Vim repository to submit them.
For example, Vim has by default no syntax files for Scala,
Go or Zimbu (among plenty of other syntax files)

-- Dominique

Ingo Karkat

unread,
May 16, 2012, 3:57:43 PM5/16/12
to vim...@googlegroups.com
On 16-May-2012 21:42, Dominique Pell� wrote:

> Ingo Karkat <sw...@ingo-karkat.de> wrote:
>
>> I would like to see runtime files treated the same way as all other
>> Vim sources. Right now, no patches are published, and Bram just
>> occasionally commits them to the repo.
>
> Aren't you using Mercurial?

Yes, I am, though I'm following vim_dev (and the posted patches) more closely,
but only re-compiling a fresh Vim every few weeks or so.

> Runtime files are now updated quite often in Mercurial. Here are the
> dates of the last 10 edits of file runtime/doc/todo.txt in Mercurial
> for example:
>
> $ hg log runtime/doc/todo.txt| grep '^date:' | head -10
> date: Tue May 01 21:14:34 2012 +0200
> date: Mon Apr 30 15:56:52 2012 +0200
> date: Thu Apr 26 20:17:03 2012 +0200
> date: Wed Apr 25 19:07:41 2012 +0200
> date: Fri Apr 13 23:04:47 2012 +0200
> date: Thu Apr 05 17:33:26 2012 +0200
> date: Wed Mar 28 20:51:51 2012 +0200
> date: Sun Mar 11 15:57:40 2012 +0100
> date: Wed Feb 22 17:30:19 2012 +0100
> date: Mon Feb 13 00:05:22 2012 +0100

That doesn't tell the whole picture.

$ hg log runtime/ | grep '^summary:' | head -10
summary: More runtime file fixes for 'compatible' mode.
summary: updated for version 7.3.514
summary: Fixed compatible mode in most runtime files.
summary: Updated runtime files, include fixes for line continuation.
summary: Updated runtime files.
summary: Updated runtime files.
summary: Updated runtime files.
summary: updated for version 7.3.492
summary: updated for version 7.3.490
summary: Updated runtime files.

Call me pedantic, but I'm missing the description of the change plus the actual
author of the patch, and I remember seeing multiple, unrelated changes thrown
into a single commit. It's not nearly as descriptive as the mailed patches, and
(for me) so hard to follow that I don't bother.

That's why I said I want them treated the same (and suggested additional
committers to lift the effort off of Bram's shoulders).

-- regards, ingo

Bram Moolenaar

unread,
May 17, 2012, 10:05:52 AM5/17/12
to Ingo Karkat, vim...@googlegroups.com
Including patches for runtime files doesn't take much of my time, under
the condition that I can include them as-is. Most time goes into
reviewing the change and making sure it doesn't break anything. Or
omits another change that was submitted before.

So, what we need is a few people who can review patches. And a
procedure that is easy to use for everybody. Especially for
maintainers, so that we make their life easier and get more volunteers
that know a specific language.

It's possible to have a repository that has the "beta-test" version of
the runtime scripts. With a small group of committers. Ideally these
people also have some scripts to check for obvious problems, such as
using line continuation without setting 'cpo'.

I can then pull files from that repository once tested and add them to
the release repository. The group of committers could send me a list of
files to pull weekly (or whenever something important was fixed). Does
that sound like a good solution?

The main repository would continue to have few commits that contain a
bunch of runtime file changes. Someone interested in the details would
have to go to the "beta-test" repository.

--
CART DRIVER: Bring out your dead!
We follow the cart through a wretched, impoverished plague-ridden village.
A few starved mongrels run about in the mud scavenging. In the open
doorway of one house perhaps we jug glimpse a pair of legs dangling from
the ceiling. In another doorway an OLD WOMAN is beating a cat against a
wall rather like one does with a mat. The cart passes round a dead donkey
or cow in the mud. And a MAN tied to a cart is being hammered to death by
four NUNS with huge mallets.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Ben Fritz

unread,
May 17, 2012, 11:17:32 AM5/17/12