[PATCH] runtime: syntax: diff: fix for modern format

[Felipe Contreras]

Nowadays most people use the unified diff, which has this format:

--- a/foo
+++ b/foo

In that case the old file starts with '---', but currently that's
considered the new file, since the old context format is like:

*** a/foo
--- b/foo

Let's use the modern format by default, and leave the option for users
to use the old format with `diff_context = 1`.

Signed-off-by: Felipe Contreras <felipe.c...@gmail.com>
---
runtime/syntax/diff.vim | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/runtime/syntax/diff.vim b/runtime/syntax/diff.vim
index b656cd97a..b9e5131e0 100644
--- a/runtime/syntax/diff.vim
+++ b/runtime/syntax/diff.vim
@@ -346,11 +346,15 @@ syn match diffLine "^---$"
syn match diffLine "^\d\+\(,\d\+\)\=[cda]\d\+\>.*"

syn match diffFile "^diff\>.*"
-syn match diffFile "^+++ .*"
syn match diffFile "^Index: .*"
syn match diffFile "^==== .*"
-syn match diffOldFile "^\*\*\* .*"
-syn match diffNewFile "^--- .*"
+if !exists("diff_context")
+ syn match diffOldFile "^--- .*"
+ syn match diffNewFile "^+++ .*"
+else
+ syn match diffOldFile "^\*\*\* .*"
+ syn match diffNewFile "^--- .*"
+end

" Used by git
syn match diffIndexLine "^index \x\x\x\x.*"
--
2.29.2

[Bram Moolenaar]

I do not see a reason to omit highlighting +++, in a context diff you
would not find them.

Your patch makes the name more accurate, but at the same time makes it
more complicated. If you don't mind the name for the highlight group,
it just works already.

--
ARTHUR: But if he was dying, he wouldn't bother to carve
"Aaaaarrrrrrggghhh". He'd just say it.
BROTHER MAYNARD: It's down there carved in stone.
GALAHAD: Perhaps he was dictating.
"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 ///

[Felipe Contreras]

There's no reason to omit them.

> Your patch makes the name more accurate, but at the same time makes it
> more complicated. If you don't mind the name for the highlight group,
> it just works already.

But it doesn't work. I want to distinguish the file ("^diff\>.*" aka
diffFile) from the new file ("^+++ .*" aka diffNewFile).

So in my colorscheme I have diffNewFile: 'green', diffOldFile: 'red',
diffFile: 'blue' reversed.

https://snipboard.io/BsmkiT.jpg

How do you propose I distinguish diffFile from diffNewFile without my patch?

Cheers.

--
Felipe Contreras

[Bram Moolenaar]

Hmm, in unified diff the "***" marker isn't used, and in old style diff
"+++" isn't used, so these could use the same highlight?

Changing:

syn match diffFile "^+++ .*"

To:

syn match diffOldFile "^+++ .*"

Would work, right?


--
Q: Why does /dev/null accept only integers?
A: You can't sink a float.

[Felipe Contreras]

On Mon, Dec 7, 2020 at 11:54 AM Bram Moolenaar <Br...@moolenaar.net> wrote:
> Felipe Contreras wrote:

> > But it doesn't work. I want to distinguish the file ("^diff\>.*" aka
> > diffFile) from the new file ("^+++ .*" aka diffNewFile).
> >
> > So in my colorscheme I have diffNewFile: 'green', diffOldFile: 'red',
> > diffFile: 'blue' reversed.
> >
> > https://snipboard.io/BsmkiT.jpg
> >
> > How do you propose I distinguish diffFile from diffNewFile without my patch?
>
> Hmm, in unified diff the "***" marker isn't used, and in old style diff
> "+++" isn't used, so these could use the same highlight?
>
> Changing:
>
> syn match diffFile "^+++ .*"
>
> To:
>
> syn match diffOldFile "^+++ .*"
>
> Would work, right?

Yes. That works.

It's annoying that the order is reversed for the vastly most widely
used format, but it works.

Perhaps at least some comment?

--- a/runtime/syntax/diff.vim
+++ b/runtime/syntax/diff.vim
@@ -346,12 +346,14 @@ syn match diffLine "^---$"

syn match diffLine "^\d\+\(,\d\+\)\=[cda]\d\+\>.*"

syn match diffFile "^diff\>.*"
-syn match diffFile "^+++ .*"
syn match diffFile "^Index: .*"
syn match diffFile "^==== .*"

syn match diffOldFile "^\*\*\* .*"

syn match diffNewFile "^--- .*"

+" In unified diff this is actually the new file
+syn match diffOldFile "^+++ .*"
+

" Used by git
syn match diffIndexLine "^index \x\x\x\x.*"

--
Felipe Contreras

[Felipe Contreras]

Hello?

--
Felipe Contreras

[Christian Brabandt]

On Di, 15 Dez 2020, Felipe Contreras wrote:

> Hello?

Hello again :)

I think it has been included as of
https://github.com/vim/vim/commit/1b884a0053982335f644eec6c71027706bf3c522

Best,
Christian
--
Man gewöhnt sich an alles, sogar an sich selbst.

[Felipe Contreras]

On Wednesday, December 16, 2020 at 2:13:39 AM UTC-6 cbl...@256bit.org wrote:

I think it has been included as of
https://github.com/vim/vim/commit/1b884a0053982335f644eec6c71027706bf3c522

Didn't you just argued in issue #7574 that contributors are mentioned in the commit message?

Where is my attribution?

[Christian Brabandt]

Are you trolling? Runtime files are typically updated in batches (and
might be maintained by others upstream). But I am sure you know that
already.

Best,
Christian
--
Dem großen Publikum ist ein Buch nicht leicht zu schlecht, sehr
leicht aber zu gut.
-- Marie von Ebner-Eschenbach

[Felipe Contreras]

On Wed, Dec 30, 2020 at 7:56 AM Christian Brabandt <cbl...@256bit.org> wrote:
> On Mi, 30 Dez 2020, Felipe Contreras wrote:

> > Didn't you just argued in issue #7574 that contributors are mentioned in the commit message?
> >
> > Where is my attribution?
>
> Are you trolling?

No.

> Runtime files are typically updated in batches (and
> might be maintained by others upstream).

Therefore there's **zero** attribution.

> But I am sure you know that already.

Yes. I know there's no attribution.

Either there's attribution or there isn't.

--
Felipe Contreras

[Christian Brabandt]

On Mi, 30 Dez 2020, Felipe Contreras wrote:
> Yes. I know there's no attribution.
>
> Either there's attribution or there isn't.

There is attribution to the changes in the Core C files, which make the
core of Vim.

Best,
Christian
--
Die Philosophen verdammen den Reichtum nur, weil wir ihn schlecht
gebrauchen.
-- François de La Rochefoucauld

[Felipe Contreras]

On Wed, Dec 30, 2020 at 8:11 AM Christian Brabandt <cbl...@256bit.org> wrote:
> On Mi, 30 Dez 2020, Felipe Contreras wrote:
> > Yes. I know there's no attribution.
> >
> > Either there's attribution or there isn't.
>
> There is attribution to the changes in the Core C files, which make the
> core of Vim.

So not all contributions have attribution, which is an extremely easy
thing to give since at least 15 years.

--
Felipe Contreras

[Bram Moolenaar]

I find it scary that I can dig up what someone has done a dozen years ago
in some repository. Suppose you apply or a new job and the recruiter
goes to github to dig up all the pull requests you ever made?

It may seem nice now to show to your friends what you contributed, but
you may regret that later. In a way github is like Facebook without a
delete button...

You can always create a repository that shows your contributions. Then
you have control over what shows up and what doesn't.

--
hundred-and-one symptoms of being an internet addict:
48. You get a tatoo that says "This body best viewed with Netscape 3.1 or
higher."

[Felipe Contreras]

On Wed, Dec 30, 2020 at 10:48 AM Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>
> Felipe Contreras wrote:
>
> > On Wed, Dec 30, 2020 at 8:11 AM Christian Brabandt <cbl...@256bit.org> wrote:
> > > On Mi, 30 Dez 2020, Felipe Contreras wrote:
> > > > Yes. I know there's no attribution.
> > > >
> > > > Either there's attribution or there isn't.
> > >
> > > There is attribution to the changes in the Core C files, which make the
> > > core of Vim.
> >
> > So not all contributions have attribution, which is an extremely easy
> > thing to give since at least 15 years.
>
> I find it scary that I can dig up what someone has done a dozen years ago
> in some repository.

And what about the rest of us?

If I don't want my name in a patch, I don't use my name in a patch.

> Suppose you apply or a new job and the recruiter
> goes to github to dig up all the pull requests you ever made?

That's a plus.

Moreover, the whole open source industry considers keeping track of
contributions for legal reasons a good thing.

https://developercertificate.org/

--
Felipe Contreras

[Christian Brabandt]

> Am 30.12.2020 um 18:05 schrieb Felipe Contreras <felipe.c...@gmail.com>:.

>> I find it scary that I can dig up what someone has done a dozen years ago
>> in some repository.
>

> And what about the rest of us?.

It's actually a good thing. If data has not been collected, it can't be abused. That it better than what is happening in the rest of the world today. Think about everybody complaining about the data that is gathered by Facebook and Google....

Christian

[Felipe Contreras]

On Wed, Dec 30, 2020 at 11:38 AM Christian Brabandt <c...@256bit.org> wrote:
> > Am 30.12.2020 um 18:05 schrieb Felipe Contreras <felipe.c...@gmail.com>:.
> >> I find it scary that I can dig up what someone has done a dozen years ago
> >> in some repository.
> >
> > And what about the rest of us?.
>
> It's actually a good thing.

So you are going to disregard my opinion and presume you know what's
best for me?

Regardless of your opinion (which is just an opinion), millions of
programmers use git, and they are fine with their information (real or
alias) being stored forever in every single commit.

--
Felipe Contreras

[Christian Brabandt]

> Am 30.12.2020 um 18:49 schrieb Felipe Contreras <felipe.c...@gmail.com>:

>
> On Wed, Dec 30, 2020 at 11:38 AM Christian Brabandt <c...@256bit.org> wrote:
>>> Am 30.12.2020 um 18:05 schrieb Felipe Contreras <felipe.c...@gmail.com>:.
>>>> I find it scary that I can dig up what someone has done a dozen years ago
>>>> in some repository.
>>>
>>> And what about the rest of us?.
>>
>> It's actually a good thing.
>
> So you are going to disregard my opinion and presume you know what's
> best for me?

No, I just think being conservative with what data is being collected is actually a good thing. But that is just my opinion. Feel free to disagree.

Christian

[Felipe Contreras]

Precisely. So if you think being "conservative" with what data is
being collected is a good thing, then you do that. (Others might do
s/conservative/paranoid/ to describe the situation at hand).

So my comment still stands: what about the rest of us?

In 20 years of experience contributing to open source software, I have
**never** heard of a single person saying "please don't record my real
name".

Those hypothetical users--which are very likely less than 1 in 10,000
(if they exist at all)--can simply configure git with a pseudonym.

Cheers.

--
Felipe Contreras

[Christian Brabandt]

> Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:
>
> On Wed, Dec 30, 2020 at 12:09 PM Christian Brabandt <cbl...@256bit.org> wrote

>>
>>
>> No, I just think being conservative with what data is being collected is actually a good thing. But that is just my opinion. Feel free to disagree.
>
> Precisely. So if you think being "conservative" with what data is
> being collected is a good thing, then you do that. (Others might do
> s/conservative/paranoid/ to describe the situation

Well this is how this project works. As I said feel free to disagree, it is not like you are forced to contribute 🙈

Now you can have the last word.

Thanks,
Christian

[Felipe Contreras]

On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:

> > Precisely. So if you think being "conservative" with what data is
> > being collected is a good thing, then you do that. (Others might do
> > s/conservative/paranoid/ to describe the situation
>
> Well this is how this project works.

Yes, it works by not giving credit to contributors.

This is the naturalistic fallacy; just because something is the case
doesn't mean it **should** be the case. And by that logic that's the
reply all projects can give to any suggestions for improvement: "this

is how this project works".

The fact remains you don't give credit, and that's what issue #7574
was all about, where you said "Note: that contribution is always
welcome and given in the commit message", which is clearly not true.

Caleb Tillman made a very simple fix on the tests of the Git project
[1], and he was mentioned in the release notes [2]. Why? Because he
contributed.

The vim project simply doesn't do what the Git project does; give attribution.

Cheers.

[1] https://git.kernel.org/pub/scm/git/git.git/commit/?id=ac9b547548
[2] https://lore.kernel.org/git/xmqqk0t1...@gitster.c.googlers.com/

--
Felipe Contreras

[Bram Moolenaar]

Filipe Contreras wrote:

> In 20 years of experience contributing to open source software, I have
> **never** heard of a single person saying "please don't record my real
> name".

I have, many times. And also quite a few names on changes are not the
actual name of the person but an alias. I don't know how many.

Also, lots of people don't realize there is a problem until it's too
late. Programmers are hopefully better than the average Facebook user.

--
Q: What is a patch 22?
A: A patch you need to include to make it possible to include patches.

[Bram Moolenaar]

Felipe Contreras wrote:

> On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:
>
> > > Precisely. So if you think being "conservative" with what data is
> > > being collected is a good thing, then you do that. (Others might do
> > > s/conservative/paranoid/ to describe the situation
> >
> > Well this is how this project works.
>
> Yes, it works by not giving credit to contributors.

There are credits for many contributors all over the place.

> The vim project simply doesn't do what the Git project does; give
> attribution.

You appear to only look at Github. That is just one of the many places
where software development happens. And one of the many ways software
development can be done. There is no "one right way". Just popular
and less popular ways, and it changes over time.

If someone would like to be credited, just ask. Several runtime files
mention contributors. And you don't need to go to Github to find that,
also people who find Vim pre-installed on their computer can see this.
They also show up in search results.

The mailing list archives contain lots of suggestions, complaints,
discussions, etc. Many of these are not changes to the distributed
files, but they do help Vim progress. I find great help in people
providing a reproducible example, do we need to credit them explicitly,
make a list? I think most people are just happy we responded and fixed
their problem or added a feature.

Also, some people don't want to be mentioned. Some users on Github use
a made-up name, and even when I know their actual name I won't mention
it, because they might not want to (or even explicitly asked me not to).

--
hundred-and-one symptoms of being an internet addict:

53. To find out what time it is, you send yourself an e-mail and check the
"Date:" field.

[Felipe Contreras]

On Wed, Dec 30, 2020 at 3:05 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
> Felipe Contreras wrote:
>
> > On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > > > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:
> >
> > > > Precisely. So if you think being "conservative" with what data is
> > > > being collected is a good thing, then you do that. (Others might do
> > > > s/conservative/paranoid/ to describe the situation
> > >
> > > Well this is how this project works.
> >
> > Yes, it works by not giving credit to contributors.
>
> There are credits for many contributors all over the place.

There are some credits, for some of the contributions, of some of the
contributors. Not all, not even most.

Can you point me to the actual diff of any contribution of anybody
other than you?

> > The vim project simply doesn't do what the Git project does; give
> > attribution.
>
> You appear to only look at Github.

I'm most definitely not. I'm looking at git:

git -C git shortlog -n --no-merges -s v2.29.0..v2.30.0

That gives me 83 contributors. for a period of 2 months.

git -C vim shortlog -n --no-merges -s v8.1.0000..v8.2.0

That gives me 2 contributors, for a period of more than 2 years.

2500 Bram Moolenaar
1 Christian Brabandt

> That is just one of the many places where software development
> happens. And one of the many ways software development can be done.

GitHub is not a software development "way"; it's a code hosting
provider, and I'm not even looking at it.

> There is no "one right way". Just popular
> and less popular ways, and it changes over time.

No. There are objectively better and worse ways of doing things.

For example; we are replying in interleaved style [1], but some people
use top-posting. Do you think both styles are equally "right"? Or is
one way objectively better than the other?

> If someone would like to be credited, just ask.

Contributors shouldn't need to ask the project to do the right thing,
just like you shouldn't ask your neighbors to not play loud music at 3
A.M.

> I think most people are just happy we responded and fixed
> their problem or added a feature.

Yes, that's not an argument against doing the right thing; give credit
where credit is due.

> Also, some people don't want to be mentioned.

If these people actually exist, they can simply request to not be mentioned.

You don't make rules to inconvenience 99.99% of the population. You
inconvenience the minority, but still accommodate it. Some people may
be rich enough that they don't need or want a salary, but you don't
make 99.99% of the workers request their salary every month.

It's the minority that should opt-out of the most common behavior.

Cheers.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[1] https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

--
Felipe Contreras

[Yegappan Lakshmanan]

Hi,

On Wed, Dec 30, 2020 at 2:01 PM Felipe Contreras <felipe.c...@gmail.com> wrote:

On Wed, Dec 30, 2020 at 3:05 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
> Felipe Contreras wrote:
>
> > On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > > > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:
> >
> > > > Precisely. So if you think being "conservative" with what data is
> > > > being collected is a good thing, then you do that. (Others might do
> > > > s/conservative/paranoid/ to describe the situation
> > >
> > > Well this is how this project works.
> >
> > Yes, it works by not giving credit to contributors.
>
> There are credits for many contributors all over the place.

There are some credits, for some of the contributions, of some of the
contributors. Not all, not even most.

I have contributed many patches in the past 20 years to Vim. When Bram

sends out a patch, he includes the name of the author in the patch

header. Also, when someone reports a problem, Bram includes their

name in the patch.

All the patches included in a particular Vim release are listed in the

version<n>.txt file. You can get the name of the author of a patch from

these files. For example, you can open version6.txt or version7.txt and

version8.txt and search for the author name.

Also, the authors who have contributed significantly to VIm are listed

under ":help credits".

Regards,

Yegappan

[Tony Mechelynck]

Like Yegappan said, many contributors are mentioned under ":help
credits". Christian and Yegappan are there at the very bottom (they
are "last but not least") and I am there too, though I didn't
specifically ask for it AFAIR, and I feel flattered, though as far as
I'm concerned, "by Bram Moolenaar et al." (which appears on the
":intro" splash page) would have been enough. I do what I feel is my
duty — I contribute within the limits of my capabilities in exchange
for free use of this fine product — and the only credit I need is that
of my own conscience. Everything else is extra: I welcome it but I
don't run after it and I don't require it. YMMV, but this is Bram's
backyard, ball and bat: anyone is welcome to play (as long as he
doesn't make a nuisance of himself) but he makes the rules.

Thanks for flying Vim anyway.

Best regards,
Tony.

[Felipe Contreras]

On Wed, Dec 30, 2020 at 3:05 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>

> Filipe Contreras wrote:

It's Felipe.

> > In 20 years of experience contributing to open source software, I have
> > **never** heard of a single person saying "please don't record my real
> > name".
>

> I have, many times. I don't know how many.

How many in the last 10 years? 1? 10? 100?

> And also quite a few names on changes are not the actual name of the
> person but an alias.

There shouldn't be any problem with git saying the author of the patch
is an alias.

> Also, lots of people don't realize there is a problem until it's too
> late. Programmers are hopefully better than the average Facebook user.

Which programmers? The programmers submitting the patches, or the
programmers receiving the patches?

The needs of the few should not outweigh the needs of the many.

It doesn't make sense to make 99,999 programmers suffer all the time
because 1 might make a mistake once.

--
Felipe Contreras

[Felipe Contreras]

Hello,

On Wed, Dec 30, 2020 at 4:33 PM Yegappan Lakshmanan <yega...@gmail.com> wrote:
> On Wed, Dec 30, 2020 at 2:01 PM Felipe Contreras <felipe.c...@gmail.com> wrote:

>> There are some credits, for some of the contributions, of some of the
>> contributors. Not all, not even most.
>
> I have contributed many patches in the past 20 years to Vim. When Bram
> sends out a patch, he includes the name of the author in the patch
> header. Also, when someone reports a problem, Bram includes their
> name in the patch.

That doesn't include the authors that contribute to the runtime.

--
Felipe Contreras

[Felipe Contreras]

On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
<antoine.m...@gmail.com> wrote:
>
> Like Yegappan said, many contributors are mentioned under ":help
> credits".

I wouldn't say 65 is "many". You can easily find 1843 contributors of git.

Many more vim contributors are missing, especially if they worked on
the runtime.

> Everything else is extra: I welcome it but I don't run after it and I
> don't require it.

I don't require it either. Just like I don't require a gift back in a
gift exchange, but it is expected.

> YMMV, but this is Bram's backyard, ball and bat: anyone is welcome to

> play but he makes the rules.

That's the naturalistic fallacy again. Yes, Bram can do whatever he
wants, but that doesn't mean what he wants is necessarily the best for
the project.

No one is infallible.

Cheers.

--
Felipe Contreras

[Christian Brabandt]

On Mi, 30 Dez 2020, Felipe Contreras wrote:

As has been pointed out, runtime files are different. Some of them are
maintained in separate repositories, so contributors get credit there
(check the Codeowners file). Then you can tell by all the "I'll iclude"
messages at closed PRs that people contributed.

But you have to draw a line somewhere. Where should it end, should we
also credit people who gave feedback? What about the people that found a
bug? Shouldn't they also be credited? What about people who helped with
the infrastructure? Shouldn't those be credited? What about random
articles on the internet criticizing Bram? Do they deserve credits?


Best,
Christian
--
Stilblüten aus Schreiben von Versicherungsnehmern:
Ich erlitt dadurch einen Unfall, daß das Moped Ihres Versicherungsnehmers
mich mit unverminderter Pferdestärke anraste.

[Christian Brabandt]

On Mi, 30 Dez 2020, Felipe Contreras wrote:

> On Wed, Dec 30, 2020 at 3:05 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
> > Felipe Contreras wrote:
> >
> > > On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > > > > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:
> > >
> > > > > Precisely. So if you think being "conservative" with what data is
> > > > > being collected is a good thing, then you do that. (Others might do
> > > > > s/conservative/paranoid/ to describe the situation
> > > >
> > > > Well this is how this project works.
> > >
> > > Yes, it works by not giving credit to contributors.
> >
> > There are credits for many contributors all over the place.
>
> There are some credits, for some of the contributions, of some of the
> contributors. Not all, not even most.
>
> Can you point me to the actual diff of any contribution of anybody
> other than you?
>
> > > The vim project simply doesn't do what the Git project does; give
> > > attribution.
> >
> > You appear to only look at Github.
>
> I'm most definitely not. I'm looking at git:
>
> git -C git shortlog -n --no-merges -s v2.29.0..v2.30.0
>
> That gives me 83 contributors. for a period of 2 months.

git is irrelevant here.

>
> git -C vim shortlog -n --no-merges -s v8.1.0000..v8.2.0
>
> That gives me 2 contributors, for a period of more than 2 years.
>
> 2500 Bram Moolenaar
> 1 Christian Brabandt

As has been mentioned, the --author is not used here. Credits are given
in the commit message. Check those. Or check the help page.

>
> > That is just one of the many places where software development
> > happens. And one of the many ways software development can be done.
>
> GitHub is not a software development "way"; it's a code hosting
> provider, and I'm not even looking at it.
>
> > There is no "one right way". Just popular
> > and less popular ways, and it changes over time.
>
> No. There are objectively better and worse ways of doing things.

objective by what standards? And who are you to dictate what workflows
are used by a project that is 30 years old?

> For example; we are replying in interleaved style [1], but some people
> use top-posting. Do you think both styles are equally "right"? Or is
> one way objectively better than the other?

That is an interesting question. Because the interleaved style has lost
already which I think is (at least) partially caused by people starting
to use smartphones to read and answer mails. You may not like it, but it
is by no means the "objective" better way.


Best,
Christian
--
Hallo Häkelschwester!

[Christian Brabandt]

On Mi, 30 Dez 2020, Felipe Contreras wrote:

> On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
> <antoine.m...@gmail.com> wrote:
> >
> > Like Yegappan said, many contributors are mentioned under ":help
> > credits".
>
> I wouldn't say 65 is "many". You can easily find 1843 contributors of git.

I am not sure why you keep mentioning git here. The git project is
irrelevant for the vim project. Also it is not just 65. Read the help or
the commit messages. Or check github PRs. Oh way, here are some more:
https://gist.github.com/romainl/7b17317cc26a30116e51a37590229b7d

And the thing is, you can easily find out, even if you do not use git
and clone the source repo. If you have vim installed, you can see the
credits (in the help file).

> Many more vim contributors are missing, especially if they worked on
> the runtime.

They may get credits in the upstream repos, depending on how the
upstream maintainer works.

Best,
Christian
--
Die schlimmste Krankheit ist die Gleichgültigkeit. Na und?

[Felipe Contreras]

On Thu, Dec 31, 2020 at 2:34 AM Christian Brabandt <cbl...@256bit.org> wrote:
> On Mi, 30 Dez 2020, Felipe Contreras wrote:

> > On Wed, Dec 30, 2020 at 4:33 PM Yegappan Lakshmanan <yega...@gmail.com> wrote:
> > > On Wed, Dec 30, 2020 at 2:01 PM Felipe Contreras <felipe.c...@gmail.com> wrote:
> >
> > >> There are some credits, for some of the contributions, of some of the
> > >> contributors. Not all, not even most.
> > >
> > > I have contributed many patches in the past 20 years to Vim. When Bram
> > > sends out a patch, he includes the name of the author in the patch
> > > header. Also, when someone reports a problem, Bram includes their
> > > name in the patch.
> >
> > That doesn't include the authors that contribute to the runtime.
>
> As has been pointed out, runtime files are different.

This is the naturalistic fallacy again.

The fact that they are different doesn't mean they should be different.

> Some of them are maintained in separate repositories, so contributors
> get credit there (check the Codeowners file).

So? Many of the subsystems of Linux are maintained in different
repositories. And all those contributors have authorship.

Git has absolutely no problem pulling all the history of a branch from
another repository.

> But you have to draw a line somewhere.

Yes, you draw the line where the tool makes it extremely easy to
provide authorship; the line is everyone that submitted a patch.

> What about random articles on the internet criticizing Bram? Do they
> deserve credits?

This is a slippery slope fallacy [1]; you stop where it makes sense to stop.

[1] https://en.wikipedia.org/wiki/Slippery_slope

--
Felipe Contreras

[Felipe Contreras]

On Thu, Dec 31, 2020 at 2:39 AM Christian Brabandt <cbl...@256bit.org> wrote:
>
>
> On Mi, 30 Dez 2020, Felipe Contreras wrote:
>
> > On Wed, Dec 30, 2020 at 3:05 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
> > > Felipe Contreras wrote:
> > >
> > > > On Wed, Dec 30, 2020 at 1:22 PM Christian Brabandt <c...@256bit.org> wrote:
> > > > > > Am 30.12.2020 um 20:07 schrieb Felipe Contreras <felipe.c...@gmail.com>:

> > > > The vim project simply doesn't do what the Git project does; give
> > > > attribution.
> > >
> > > You appear to only look at Github.
> >
> > I'm most definitely not. I'm looking at git:
> >
> > git -C git shortlog -n --no-merges -s v2.29.0..v2.30.0
> >
> > That gives me 83 contributors. for a period of 2 months.
>
> git is irrelevant here.

No it isn't.

The Git project knows very well how to use the git tool. The vim
project doesn't.

The Git project gives attribution to each and every person that
submits a patch and it's accepted. The vim project doesn't.

> > git -C vim shortlog -n --no-merges -s v8.1.0000..v8.2.0
> >
> > That gives me 2 contributors, for a period of more than 2 years.
> >
> > 2500 Bram Moolenaar
> > 1 Christian Brabandt
>
> As has been mentioned, the --author is not used here.

Naturalistic fallacy again.

Yes, it's not used. It should be used.

> > > That is just one of the many places where software development
> > > happens. And one of the many ways software development can be done.
> >
> > GitHub is not a software development "way"; it's a code hosting
> > provider, and I'm not even looking at it.
> >
> > > There is no "one right way". Just popular
> > > and less popular ways, and it changes over time.
> >
> > No. There are objectively better and worse ways of doing things.
>
> objective by what standards?

That is the debate.

> And who are you to dictate what workflows are used by a project that
> is 30 years old?

I am not dictating anything.

I am *arguing* one way is objectively better than another way. Either
I'm right, or I'm not, but I'm providing arguments.

"This is the way it is" is not an argument.

> > For example; we are replying in interleaved style [1], but some people
> > use top-posting. Do you think both styles are equally "right"? Or is
> > one way objectively better than the other?
>
> That is an interesting question. Because the interleaved style has lost
> already

Lost what? Truth is not a popularity contest.

An objectively inferior way of doing things can be the most popular.
No conflict there.

> You may not like it, but it is by no means the "objective" better way.

Popularity has no bearing on what's objectively better.

The Earth is objectively round regardless of how many people believe so.

--
Felipe Contreras

[Felipe Contreras]

On Thu, Dec 31, 2020 at 2:44 AM Christian Brabandt <cbl...@256bit.org> wrote:
> On Mi, 30 Dez 2020, Felipe Contreras wrote:
>
> > On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
> > <antoine.m...@gmail.com> wrote:
> > >
> > > Like Yegappan said, many contributors are mentioned under ":help
> > > credits".
> >
> > I wouldn't say 65 is "many". You can easily find 1843 contributors of git.
>
> I am not sure why you keep mentioning git here.

Because they do give attribution to each and every single contributor.
So they show it's possible.

> Also it is not just 65.

If you look above in the hunk you are replying to, it was Tony
Mechelynck that said there are "many contributors" in ":help credits".

That is literally just 65.

> And the thing is, you can easily find out,

Can I? Easily? Show me a list of the top 100 contributors by number of
patches (including the runtime), and how to get it.

> > Many more vim contributors are missing, especially if they worked on
> > the runtime.
>
> They may get credits in the upstream repos, depending on how the
> upstream maintainer works.

Or they may get nothing.

--
Felipe Contreras

[Dominique Pellé]

Felipe Contreras wrote:

> On Thu, Dec 31, 2020 at 2:44 AM Christian Brabandt <cbl...@256bit.org> wrote:
> > On Mi, 30 Dez 2020, Felipe Contreras wrote:
> >
> > > On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
> > > <antoine.m...@gmail.com> wrote:
> > > >
> > > > Like Yegappan said, many contributors are mentioned under ":help
> > > > credits".
> > >
> > > I wouldn't say 65 is "many". You can easily find 1843 contributors of git.
> >
> > I am not sure why you keep mentioning git here.
>
> Because they do give attribution to each and every single contributor.
> So they show it's possible.

This discussion is getting long. Merging PRs using git (which
would give credit) is only one way to do it. It's not a must.
I assume that PRs are not merged directly using git because
Bram often wants to modify changes suggested by contributors.
Not sure how additional changes could be done if we were to
merge PRs. Bram would have to ask the contributor to make
changes until the PR is good enough, but that would take more
time and keep CI more busy. Or is there a better way?

Bram is the BDFL (Benevolent Dictator For Life) of Vim, as
opposed to neovim which is more maintained by a community.
Both ways have their pros and cons. Maintenance by a BDFL
can ensure a more consistent vision, at the cost of having a
bottleneck. Bram has created Vim and has consistently
maintained it for decades. It's his project, so he deserves
to choose how it's maintained.

That said, it's true that changes do not alway get credited,
even in the core of vim (not just runtime files). Personally, I
don't mind too much, but I can understand that it may upset
some people.

For example, the following change could have credited
Dhiraj Mishra for discovering the bug:

===
commit 5e1f22ff614821b8fc7294c9dd22765acd403aeb (tag: v8.2.1972)
Author: Bram Moolenaar <Br...@vim.org>
Date: Tue Nov 10 18:23:52 2020 +0100

patch 8.2.1972: crash when recreating nested fold

Problem: Crash when recreating nested fold.
Solution: Check for empty growarray. (closes #7278)
===

In some other cases, missing credit can be because the full
name of the contributor is not known (besides his github login
name).

For runtime files, it's more complex as explained in other
replies already. Personally, I think that changes in runtime
files could be submitted in with smaller granularity now that
we use git, which could then give credit to each change in the
git commit, as opposed to updating runtime files every 2 weeks
or so with a single commit which includes many changes.
But again, it's up to the BDFL :-)

Regards
Dominique

[Christian Brabandt]

> Am 31.12.2020 um 18:01 schrieb Felipe Contreras <felipe.c...@gmail.com>:

>
> On Thu, Dec 31, 2020 at 2:39 AM Christian Brabandt <cbl...@256bit.org> wrote:
>>
>>
>> git is irrelevant here.
>
> No it isn't.
>
> The Git project knows very well how to use the git tool. The vim
> project doesn't.

Of course it is. Git is a different project. It is irrelevant for vim how git organizes their project.

>
> The Git project gives attribution to each and every person that
> submits a patch and it's accepted. The vim project doesn't.

But not for Feedback. So what about that? Shouldn't those also be giving credit?

>
>>> git -C vim shortlog -n --no-merges -s v8.1.0000..v8.2.0
>>>
>>> That gives me 2 contributors, for a period of more than 2 years.
>>>
>>> 2500 Bram Moolenaar
>>> 1 Christian Brabandt
>>
>> As has been mentioned, the --author is not used here.
>
> Naturalistic fallacy again.
>
> Yes, it's not used. It should be used.

Says you. Or you record credit in the commit message as has been done 30 years ago, before git existed.

>
>>>> That is just one of the many places where software development
>>>> happens. And one of the many ways software development can be done.
>>>
>>> GitHub is not a software development "way"; it's a code hosting
>>> provider, and I'm not even looking at it.
>>>
>>>> There is no "one right way". Just popular
>>>> and less popular ways, and it changes over time.
>>>
>>> No. There are objectively better and worse ways of doing things.
>>
>> objective by what standards?
>
> That is the debate.
>
>> And who are you to dictate what workflows are used by a project that
>> is 30 years old?
>
> I am not dictating anything

Of course you do. Otherwise you could stop arguing here, since it is clear we will not come to an agreement here. You keep on discussing until we change something.

>
> I am *arguing* one way is objectively better than another way. Either
> I'm right, or I'm not, but I'm providing arguments.
>
> "This is the way it is" is not an argument.

You may not like it, but it is of course an argument...

>
>>> For example; we are replying in interleaved style [1], but some people
>>> use top-posting. Do you think both styles are equally "right"? Or is
>>> one way objectively better than the other?
>>
>> That is an interesting question. Because the interleaved style has lost
>> already
>
> Lost what? Truth is not a popularity contest.
>
> An objectively inferior way of doing things can be the most popular.
> No conflict there.
>
>> You may not like it, but it is by no means the "objective" better way.
>
> Popularity has no bearing on what's objectively better.
>
> The Earth is objectively round regardless of how many people believe so.

That is a fact. How people work may be different for each single one. That is no objective fact. There are different ways of doing something, regardless of what you call objectively better.

Christian

[Christian Brabandt]

> Am 31.12.2020 um 18:08 schrieb Felipe Contreras <felipe.c...@gmail.com>:

>
> On Thu, Dec 31, 2020 at 2:44 AM Christian Brabandt <cbl...@256bit.org> wrote:
>>> On Mi, 30 Dez 2020, Felipe Contreras wrote:
>>>
>>> On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
>>> <antoine.m...@gmail.com> wrote:
>>>>
>>>> Like Yegappan said, many contributors are mentioned under ":help
>>>> credits".
>>>
>>> I wouldn't say 65 is "many". You can easily find 1843 contributors of git.
>>
>> I am not sure why you keep mentioning git here.
>
> Because they do give attribution to each and every single contributor.
> So they show it's possible.

And it is irrelevant for vim...

>
>> Also it is not just 65.
>
> If you look above in the hunk you are replying to, it was Tony
> Mechelynck that said there are "many contributors" in ":help credits".
>
> That is literally just 65.

And has been mentioned, this is not the only place where you find credit.

>
>> And the thing is, you can easily find out,
>
> Can I? Easily? Show me a list of the top 100 contributors by number of
> patches (including the runtime), and how to get it.

Yes, it is all there in the help. Read it.
I am not interested in finding statistics out. But of course you can throw your favorite programming language at it.

>
>>> Many more vim contributors are missing, especially if they worked on
>>> the runtime.
>>
>> They may get credits in the upstream repos, depending on how the
>> upstream maintainer works.
>
> Or they may get nothing.

Perhaps. You can check....

Christian

[Αγαθοκλής]

Hi all,

On Thu, Dec 31, at 10:51 Felipe Contreras wrote:
> On Thu, Dec 31, 2020 at 2:34 AM Christian Brabandt <cbl...@256bit.org> wrote:
> > On Mi, 30 Dez 2020, Felipe Contreras wrote:
>
> > > On Wed, Dec 30, 2020 at 4:33 PM Yegappan Lakshmanan <yega...@gmail.com> wrote:
> > > > On Wed, Dec 30, 2020 at 2:01 PM Felipe Contreras <felipe.c...@gmail.com> wrote:
> > >
> > > >> There are some credits, for some of the contributions, of some of the
> > > >> contributors. Not all, not even most.
> > > >
> > > > I have contributed many patches in the past 20 years to Vim. When Bram
> > > > sends out a patch, he includes the name of the author in the patch
> > > > header. Also, when someone reports a problem, Bram includes their
> > > > name in the patch.
> > >
> > > That doesn't include the authors that contribute to the runtime.
> >
> > As has been pointed out, runtime files are different.
>
> This is the naturalistic fallacy again.

Hi Felipe,

I'm following these lists since my BLFS days, at 2006-2010, and i was a flucky
active participant in these legendary mailing lists, for those same years, until
the situationism decided differently for the future. But i'm still following them,
though i had developed my own vim mini clone.

So, I know most of the people, by now. I remember Christian when we (probably) first came.
He might not remember me, but i do. It was about digraphs and fetching/updating
the unicode data on the fly. Since then, he became a master in C and in software development
workflow.

I Know Tony who is from Belgium, and a developer at days, that you probably wasn't
around in earth, and me a baby. He likes to study natural languages and he cares a lot about Bram.

In fact we all love Bram. He is our Bram.

He, long ago before git, had developed a routinary patch workflow:

Patch 8.2.2249
Problem: Termcodes test is flaky when used over ssh with X forwarding.
Solution: Set 'mousetime' to a larger value. (Dominique Pellé, closes #7576, closes #7563)

This is the exact same (almost boring) routine since i remember.
I might saw all these years, thousands of them. I can not know how many, but many.

But yes, you've a right.
This kind of tracking development, doesn't offer a way to extract automatically the
information, you are seeking for. But it is there! and can be extracted easily.

In fact it seems like a nice cool idea, to gather all this information and to give a proper
summary of attributions. We all like attributions to our contributions, especially in
famous projects like vim or zsh :-). At least i do!!! :-)

I know it is an utterly fallacy, but it makes me feel warm. But what can we do?
We are common humans, and we like to feel important. Even hardcore natural punks
like yours trully.

And Buddha!, there are so many to thanks here in this quite long history (thirty
years) of development.

The quite nice thing about this development model, is that the attributions, are
hardcoded direct into the sources, so they will stay forever. Though i recognize
that git will probably stay forever too, and yes is much easier to track development.

But what i really wanted to say to you, is that we love Bram!

He contributed uncountable (probably millions) lines of code, he fixed uncountable
bugs, he participated in uncountable exchanges in the mailing lists.

Please, grep in the archives, with something like:

"([A-Z][a-z]*:.*\n)*^$\nThanks.\n"

and watch a quite long output of his appreciation to the contributors!

But even if something has been changed in these modern git days, probably it is
because of the different development workflow, which happens now in GH, instead of the
development list.

If it is so, please don't hesitate to ask him, with the exact same way you ask
something from your father, as he is a gentle by nature listener.

That's the whole trueth. So please understand.

May you all be healthy. Probably is wise also to wish for a rather boring
and without too many excitements year, really. We've still a long road to walk,
but we can see clearly the ocean now. We just have to believe in ourselves,
so we can walk this path with pride.

Regards, ag

[Felipe Contreras]

On Thu, Dec 31, 2020 at 12:26 PM Dominique Pellé
<dominiq...@gmail.com> wrote:
>
> Felipe Contreras wrote:
>
> > On Thu, Dec 31, 2020 at 2:44 AM Christian Brabandt <cbl...@256bit.org> wrote:
> > > On Mi, 30 Dez 2020, Felipe Contreras wrote:
> > >
> > > > On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck
> > > > <antoine.m...@gmail.com> wrote:
> > > > >
> > > > > Like Yegappan said, many contributors are mentioned under ":help
> > > > > credits".
> > > >
> > > > I wouldn't say 65 is "many". You can easily find 1843 contributors of git.
> > >
> > > I am not sure why you keep mentioning git here.
> >
> > Because they do give attribution to each and every single contributor.
> > So they show it's possible.
>
> This discussion is getting long.

That doesn't change the fact that the vim project doesn't give credit
to many (most?) contributions.

> Merging PRs using git (which would give credit) is only one way to do
> it. It's not a must.

And who is arguing that should be done? Certainly not me.

> I assume that PRs are not merged directly using git because Bram often
> wants to modify changes suggested by contributors.

When you do:

git pull $remote branch

You can do the fixes directly in the merge commit.

> Not sure how additional changes could be done if we
> were to merge PRs.

There's at least three ways of doing it.

> Bram would have to ask the contributor to make changes until the PR is
> good enough, but that would take more time and keep CI more busy.

Yes, it takes more time, but that shifts the burden to the contributor,
and that way the contributor learns the ropes, so the next pull request
requires less changes (from Bram or anyone). This way the contributor
does all the work, and deserves all the credit.

And that of course doesn't apply to runtime updates, which presumably
Bram trusts enough to merge as is.

> Or is there a better way?

Another way is to rebase the commits and apply the fix directly in the
commit before merging them.

The git project does it the second way: shift the burden to the contributor.

> Bram is the BDFL (Benevolent Dictator For Life) of Vim, as
> opposed to neovim which is more maintained by a community.
> Both ways have their pros and cons.

This is a false dichotomy. Both Linux and Git have a BDFL, and both
give proper attribution to all the contributors.

> It's his project, so he deserves to choose how it's maintained.

Asked and answered. Yes, it's his choice, and his choice isn't

necessarily the best for the project.

> That said, it's true that changes do not alway get credited,
> even in the core of vim (not just runtime files). Personally, I
> don't mind too much, but I can understand that it may upset
> some people.

Personally it doesn't upset me, but it's the right thing to do, and
it's not difficult at all.

> For example, the following change could have credited
> Dhiraj Mishra for discovering the bug:

And instead of extending the commit message, which is basically free,
space is wasted adding yet another two more lines to src/version.c
which serve absolutely no purpose.

> For runtime files, it's more complex as explained in other
> replies already. Personally, I think that changes in runtime
> files could be submitted in with smaller granularity now that
> we use git, which could then give credit to each change in the
> git commit, as opposed to updating runtime files every 2 weeks
> or so with a single commit which includes many changes.

Yeah, that's what merge commits are for.

> But again, it's up to the BDFL :-)

Yeah, it's up to him, but that doesn't change the fact that one way is
more fair to the contributors.

--
Felipe Contreras