Typo in help file

[Tony Mechelynck]

options.txt (latest version) line 2944

there is:
*'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*


there should be:
*'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*


Note that there are two entries for 'wic' in the help tags file (at
lines 1078 and 1079) but since they issue a search command and not a
line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
gives the wrong one, etc.


Best regards,
Tony.
--
"Nice boy, but about as sharp as a sack of wet mice."
-- Foghorn Leghorn

[Ingo Karkat]

On 05-Apr-13 20:14:34 +0200, Tony Mechelynck wrote:

> options.txt (latest version) line 2944
>
> there is:
> *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
>
>
> there should be:
> *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
>
>
> Note that there are two entries for 'wic' in the help tags file (at
> lines 1078 and 1079) but since they issue a search command and not a
> line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
> gives the wrong one, etc.

Already reported
(https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
probably already fixed; Bram's last runtime update is from Mar 19.

I'd like to use this occasion to plead for more frequent runtime
updates, ideally one commit per change (as with the patches), not the
current bulk updates. It would prevent these issues, we would always
have an up-to-date Todo list, and could effectively use Mercurial
features like log and blame for the runtime. (I would not send out patch
emails for these changes, though.)

-- regards, ingo

[Tony Mechelynck]

On 05/04/13 20:47, Ingo Karkat wrote:
> On 05-Apr-13 20:14:34 +0200, Tony Mechelynck wrote:
>
>> options.txt (latest version) line 2944
>>
>> there is:
>> *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
>>
>>
>> there should be:
>> *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
>>
>>
>> Note that there are two entries for 'wic' in the help tags file (at
>> lines 1078 and 1079) but since they issue a search command and not a
>> line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
>> gives the wrong one, etc.
>
> Already reported

ah, sorry, I missed that.

> (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
> probably already fixed; Bram's last runtime update is from Mar 19.

Well, maybe it's fixed in Bram's private repo but all I have is the
public one, https://vim.googlecode.com/hg/ , where (at changeset
8653c39b85ea dated Fri Apr 05 19:50:17 2013 +0200 and tagged v7-3-882)
it is definitely *not* fixed.

>
> I'd like to use this occasion to plead for more frequent runtime
> updates, ideally one commit per change (as with the patches), not the
> current bulk updates. It would prevent these issues, we would always
> have an up-to-date Todo list, and could effectively use Mercurial
> features like log and blame for the runtime. (I would not send out patch
> emails for these changes, though.)
>
> -- regards, ingo
>

Best regards,
Tony.
--
It is strictly forbidden to dance on Good Friday
(real standing law in Germany).

[Ben Fritz]

On Friday, April 5, 2013 1:47:13 PM UTC-5, Ingo Karkat wrote:
> Already reported
>
> (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J),
>
> probably already fixed; Bram's last runtime update is from Mar 19.
>
>
>
> I'd like to use this occasion to plead for more frequent runtime
>
> updates, ideally one commit per change (as with the patches), not the
>
> current bulk updates. It would prevent these issues, we would always
>
> have an up-to-date Todo list, and could effectively use Mercurial
>
> features like log and blame for the runtime. (I would not send out patch
>
> emails for these changes, though.)
>

I've been sitting on a draft email for a few months now that I haven't gotten around to finishing and sending.

I'd like to take this one step further. The runtime files are already largely maintained by people other than Bram. Bram, would you be opposed to using Mercurial to PULL changes to runtime files, from a separate public clone of the main Vim repository? Runtime file maintainers who like, could then maintain their files directly in a clone of the Vim repository and push to the "vim-runtime" repository whenever they have a version ready for release.

This would also facilitate applying "big" patches that happen to large groups of runtime files from time to time, it would allow for wider testing of experimental or cutting-edge runtime updates, and allow for easy "team maintenance" of runtime files where the maintainer agrees.

The last time I recall seeing a discussion along these lines was here:

https://groups.google.com/d/topic/vim_dev/XGz56RXff3g/discussion

I don't think we ever reached consensus there but there was a lot of support for such an idea. Bram, if you might be willing to "pull" runtime updates I think it will work quite well; we can work out the details in a new thread. I am quite busy but it does not take much effort to set up a public repository somewhere and periodically pull changes from a few sources; I'd be willing to help administer a runtime repository if nobody else steps forward.

I'm envisioning a full clone of the main Vim repository for the vim-runtime repository, except that a policy of "no C code changes" would be strictly enforced.

Obviously Bram's is the most important voice here, but does anyone else have input on this?

[Bram Moolenaar]

Tony Mechelynck wrote:

> options.txt (latest version) line 2944
>
> there is:
> *'fileignorecase'* *'wic'* *'nofileignorecase'* *'nowic'*
>
>
> there should be:
> *'fileignorecase'* *'fic'* *'nofileignorecase'* *'nofic'*
>
>
> Note that there are two entries for 'wic' in the help tags file (at
> lines 1078 and 1079) but since they issue a search command and not a
> line number, ":h 'wic'" always finds the wrong one, ":ts 'wic'" only
> gives the wrong one, etc.

This was already mentioned and fixed. I'll send out the update files
after checking for problems.

--
I'm writing a book. I've got the page numbers done.

/// 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 ///

[Bram Moolenaar]

The current method is working quite well. There is not much overhead
for me. Only disadvantage is that you get ten updates at the same time,
every two weeks or so. I don't think the version history is interesting
enough that someone misses it.

A new method with a repository has many new problems:
- How to control access to the public repository? Only the actual
maintainer must be allowed to check in changes. So we need a small
group of people to maintain the access rights.
- What if the maintainer can't be reached? This happens a lot.
- I still need to pull for changes once in a while, it is unlikely this
will happen more often than what happens now.
- The version in the public respository will differ from what I have. I
often reject new files or new versions of a file because it contains
mistakes.
- etc.

I think the advantage is theoretical only.

--
The difference between theory and practice, is that in theory, there
is no difference between theory and practice.

[Ingo Karkat]

On 05-Apr-13 22:16:54 +0200, Bram Moolenaar wrote:

> [2 messages deleted]

>
> The current method is working quite well. There is not much overhead
> for me. Only disadvantage is that you get ten updates at the same time,
> every two weeks or so. I don't think the version history is interesting
> enough that someone misses it.

Well, I remember at least two occasions where I pulled up the Mercurial
log (to answer a Stack Overflow question or investigate why Vim behaved
differently after an update), arrived at the commit, and then didn't
know how to proceed. "Updated runtime files" isn't exactly helpful, and
the fact that the updates may have originated from any message on
vim_dev from the preceding several weeks (or even was prompted by a
private message to Bram) makes searching for the reason tedious.

I think there should be the same level of accountability for runtime
updates in Mercurial; it's not so much more work to commit each change
separately and provide a short suitable message. It's less about the
timeliness; I'm fine with biweekly updates.

> [13 lines deleted]

-- regards, ingo

[Benjamin Fritz]

On Friday, April 5, 2013 3:16:54 PM UTC-5, Bram Moolenaar wrote:

> Ben Fritz wrote:
> >
> > I'd like to take this one step further. The runtime files are already
> > largely maintained by people other than Bram. Bram, would you be
> > opposed to using Mercurial to PULL changes to runtime files, from a
> > separate public clone of the main Vim repository? Runtime file
> > maintainers who like, could then maintain their files directly in a
> > clone of the Vim repository and push to the "vim-runtime" repository
> > whenever they have a version ready for release.
> >

> The current method is working quite well. There is not much overhead
> for me. Only disadvantage is that you get ten updates at the same time,
> every two weeks or so. I don't think the version history is interesting
> enough that someone misses it.
>

Obviously if it doesn't work for you, then it doesn't work.

But, while the current method works great for you, it's not as nice for the
maintainers.

Conceptually, all the runtime files are part of Vim. They should be
maintainable within a clone of the Vim repository. New potential
contributors who want to change something should be able to get a clone of
the Vim repository and start hacking. If every maintainer works in their own
little custom repository it causes headaches in merging later.

If a maintainer DOES choose to edit their files in a clone of Vim's
repostory, they face the problem that none of their commits will ever be an
ancestor of any commits on trunk. So they will have their own personal
branch forever. I've made my branch explicit in my clone for TOhtml to make
things easier to keep track of, but it is still quite annoying when I go to
make an update after a long absence, because I need to merge in a bunch of
files from the default branch, even though the TOhtml files I'm pulling in
are identical (minus timestamps).

Finally, as Ingo points out, tracking what changed in any given runtime
update is tricky. This would be easier if you could see the history. I DO
think the history is interesting, and I don't think anything would be lost
by showing it, "warts and all" as Mercurial types like to say. You would
still presumably tag each C code update, and would pull/merge runtime
updates in batches, so the "main" line of the default branch would remain
much the same as it is now. The only difference is that runtime updates
would have a second parent which could be examined to see what changed and
how.

> A new method with a repository has many new problems:
> - How to control access to the public repository? Only the actual
> maintainer must be allowed to check in changes. So we need a small
> group of people to maintain the access rights.

I was thinking that a small team of only a few people would control the
public vim-runtime or vim-unstable or whatever repository. They get changes
from maintainers on vim_dev and do a quick review before pushing to the
repository. Maintainers could email files as they have been doing, but would
be encouraged to set up a clone of the vim repository as well so that the
vim-runtime admins can just pull the changes with Mercurial as well.

> - What if the maintainer can't be reached? This happens a lot.

This is a separate problem that happens now as well. I don't see using
Mercurial causing any additional problems in this area. And it could make
things better. Some maintainers might opt for a more team-maintenance mode
for their files so that if they don't respond for a while, important patches
like the 'cpo' handling can be applied without them. Other maintainers might
drop out for a while, but will easily be able to see what changes have been
made and against which version of their files when and if they come back.

> - I still need to pull for changes once in a while, it is unlikely this
> will happen more often than what happens now.

That's OK. If users are interested in getting changes faster, they can pull
them into their own private repository clone. Otherwise, they can wait for
your blessing on a "stable" version. Right now there is no way for users to
get changes faster unless the maintainer CCs vim_dev when sending you a new
version.

And I agree with Ingo here, I don't care as much about the speed of updates,
as I care about being able to see quickly what happened in those updates.
Currently when you push a set of revisions, I glance at the commit log for
each C code change, but I then go into every runtime file of interest to me
and examine the changes to figure out what happened there. You could make
this a lot better by writing brief summaries of the content of those runtime
updates.

Since Vim is already developed in Mercurial, I think it would be less work
for you to just make the changelog of the runtime files visible to anybody
interested in what changes were made and why.

> - The version in the public respository will differ from what I have. I
> often reject new files or new versions of a file because it contains
> mistakes.

It may differ somewhat, but if you make changes also in Mercurial those will
be tracked as well. I presume you normally alert the maintainer if there are
problems; the maintainer can fix them before you pull instead.

>
> I think the advantage is theoretical only.

I think the advantage is flexibility. Your workflow is working for a lot of
people. Heck, it's actually working for me. I just think it could be a
little better and a little smoother around the edges, and I think the
community as a whole could benefit from Mercurial being used closer to its
full potential.

If you're still not open to the idea, I'll drop it now, but I thought I'd
speak up while the subject was fresh again.

And since I suppose I've hijacked Ingo's request, I'd also like you to
consider at least adding a summary of changes for runtime updates, if you
don't like the idea of pulling in all the development history.
One-commit-per-update would also work if it had a succinct summary like the
patch updates (but you don't need to send an email for each probably).