[PATCH 1/3] syntax: sh: improve heredoc delimiter identifier regex

[Felipe Contreras]

There has to be at least one character, so we should use + instead of *.

This makes the following:

cat <<-\
EOF
$foobar
EOF

Be matched by shRedir26 properly, instead of shRedir32, which doesn't
work.

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

diff --git a/runtime/syntax/sh.vim b/runtime/syntax/sh.vim
index 5ca5bc6..c042c82 100644
--- a/runtime/syntax/sh.vim
+++ b/runtime/syntax/sh.vim
@@ -348,34 +348,34 @@ if version < 600
syn region shHereDoc matchgroup=shRedir06 start="<<-\s*\**\.\**" matchgroup=shRedir06 end="^\s*\.$" contains=@shDblQuoteList

elseif s:sh_fold_heredoc
- syn region shHereDoc matchgroup=shRedir07 fold start="<<\s*\z([^ \t|]*\)" matchgroup=shRedir07 end="^\z1\s*$" contains=@shDblQuoteList
- syn region shHereDoc matchgroup=shRedir08 fold start="<<\s*\"\z([^ \t|]*\)\"" matchgroup=shRedir08 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir09 fold start="<<\s*'\z([^ \t|]*\)'" matchgroup=shRedir09 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir10 fold start="<<-\s*\z([^ \t|]*\)" matchgroup=shRedir10 end="^\s*\z1\s*$" contains=@shDblQuoteList
- syn region shHereDoc matchgroup=shRedir11 fold start="<<-\s*\"\z([^ \t|]*\)\"" matchgroup=shRedir11 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir12 fold start="<<-\s*'\z([^ \t|]*\)'" matchgroup=shRedir12 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir13 fold start="<<\s*\\\_$\_s*\z([^ \t|]*\)" matchgroup=shRedir13 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir14 fold start="<<\s*\\\_$\_s*\"\z([^ \t|]*\)\"" matchgroup=shRedir14 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir15 fold start="<<-\s*\\\_$\_s*'\z([^ \t|]*\)'" matchgroup=shRedir15 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir16 fold start="<<-\s*\\\_$\_s*\z([^ \t|]*\)" matchgroup=shRedir16 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir17 fold start="<<-\s*\\\_$\_s*\"\z([^ \t|]*\)\"" matchgroup=shRedir17 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir18 fold start="<<\s*\\\_$\_s*'\z([^ \t|]*\)'" matchgroup=shRedir18 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir19 fold start="<<\\\z([^ \t|]*\)" matchgroup=shRedir19 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir07 fold start="<<\s*\z([^ \t|]\+\)" matchgroup=shRedir07 end="^\z1\s*$" contains=@shDblQuoteList
+ syn region shHereDoc matchgroup=shRedir08 fold start="<<\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir08 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir09 fold start="<<\s*'\z([^ \t|]\+\)'" matchgroup=shRedir09 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir10 fold start="<<-\s*\z([^ \t|]\+\)" matchgroup=shRedir10 end="^\s*\z1\s*$" contains=@shDblQuoteList
+ syn region shHereDoc matchgroup=shRedir11 fold start="<<-\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir11 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir12 fold start="<<-\s*'\z([^ \t|]\+\)'" matchgroup=shRedir12 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir13 fold start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir13 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir14 fold start="<<\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir14 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir15 fold start="<<-\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir15 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir16 fold start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir16 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir17 fold start="<<-\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir17 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir18 fold start="<<\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir18 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir19 fold start="<<\\\z([^ \t|]\+\)" matchgroup=shRedir19 end="^\z1\s*$"

else
- syn region shHereDoc matchgroup=shRedir20 start="<<\s*\\\=\z([^ \t|]*\)" matchgroup=shRedir20 end="^\z1\s*$" contains=@shDblQuoteList
- syn region shHereDoc matchgroup=shRedir21 start="<<\s*\"\z([^ \t|]*\)\"" matchgroup=shRedir21 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir22 start="<<-\s*\z([^ \t|]*\)" matchgroup=shRedir22 end="^\s*\z1\s*$" contains=@shDblQuoteList
- syn region shHereDoc matchgroup=shRedir23 start="<<-\s*'\z([^ \t|]*\)'" matchgroup=shRedir23 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir24 start="<<\s*'\z([^ \t|]*\)'" matchgroup=shRedir24 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir25 start="<<-\s*\"\z([^ \t|]*\)\"" matchgroup=shRedir25 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir26 start="<<\s*\\\_$\_s*\z([^ \t|]*\)" matchgroup=shRedir26 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir27 start="<<-\s*\\\_$\_s*\z([^ \t|]*\)" matchgroup=shRedir27 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir28 start="<<-\s*\\\_$\_s*'\z([^ \t|]*\)'" matchgroup=shRedir28 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir29 start="<<\s*\\\_$\_s*'\z([^ \t|]*\)'" matchgroup=shRedir29 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir30 start="<<\s*\\\_$\_s*\"\z([^ \t|]*\)\"" matchgroup=shRedir30 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir31 start="<<-\s*\\\_$\_s*\"\z([^ \t|]*\)\"" matchgroup=shRedir31 end="^\s*\z1\s*$"
- syn region shHereDoc matchgroup=shRedir32 start="<<\\\z([^ \t|]*\)" matchgroup=shRedir32 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir20 start="<<\s*\\\=\z([^ \t|]\+\)" matchgroup=shRedir20 end="^\z1\s*$" contains=@shDblQuoteList
+ syn region shHereDoc matchgroup=shRedir21 start="<<\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir21 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir22 start="<<-\s*\z([^ \t|]\+\)" matchgroup=shRedir22 end="^\s*\z1\s*$" contains=@shDblQuoteList
+ syn region shHereDoc matchgroup=shRedir23 start="<<-\s*'\z([^ \t|]\+\)'" matchgroup=shRedir23 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir24 start="<<\s*'\z([^ \t|]\+\)'" matchgroup=shRedir24 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir25 start="<<-\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir25 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir26 start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir26 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir27 start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir27 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir28 start="<<-\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir28 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir29 start="<<\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir29 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir30 start="<<\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir30 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir31 start="<<-\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir31 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir32 start="<<\\\z([^ \t|]\+\)" matchgroup=shRedir32 end="^\z1\s*$"
endif

" Here Strings: {{{1
--
1.9.3+fc1~5~gfaddd51

[Felipe Contreras]

I noticed a bunch of issues while representing perfectly valid here documents.

cat <<-\EOF
$foobar
EOF

cat <<\
EOF
$foobar
EOF

cat <<-\
\EOF
$foobar
EOF

Felipe Contreras (3):
syntax: sh: improve heredoc delimiter identifier regex
syntax: sh: fix representation of unquoted heredoc
syntax: sh: add missing quoted heredoc syntax

runtime/syntax/sh.vim | 60 +++++++++++++++++++++++++++++----------------------
1 file changed, 34 insertions(+), 26 deletions(-)

--
1.9.3+fc1~5~gfaddd51

[Felipe Contreras]

Otherwise code such as:

cat <<\
EOF
$foobar
EOF

Is assumed to be single quoted, when it's double quoted.

Signed-off-by: Felipe Contreras <felipe.c...@gmail.com>
---

runtime/syntax/sh.vim | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/runtime/syntax/sh.vim b/runtime/syntax/sh.vim
index c042c82..d9d7606 100644
--- a/runtime/syntax/sh.vim
+++ b/runtime/syntax/sh.vim
@@ -354,10 +354,10 @@ elseif s:sh_fold_heredoc

syn region shHereDoc matchgroup=shRedir10 fold start="<<-\s*\z([^ \t|]\+\)" matchgroup=shRedir10 end="^\s*\z1\s*$" contains=@shDblQuoteList

syn region shHereDoc matchgroup=shRedir11 fold start="<<-\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir11 end="^\s*\z1\s*$"

syn region shHereDoc matchgroup=shRedir12 fold start="<<-\s*'\z([^ \t|]\+\)'" matchgroup=shRedir12 end="^\s*\z1\s*$"

- syn region shHereDoc matchgroup=shRedir13 fold start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir13 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir13 fold start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir13 end="^\z1\s*$" contains=@shDblQuoteList

syn region shHereDoc matchgroup=shRedir14 fold start="<<\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir14 end="^\z1\s*$"

syn region shHereDoc matchgroup=shRedir15 fold start="<<-\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir15 end="^\s*\z1\s*$"

- syn region shHereDoc matchgroup=shRedir16 fold start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir16 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir16 fold start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir16 end="^\s*\z1\s*$" contains=@shDblQuoteList

syn region shHereDoc matchgroup=shRedir17 fold start="<<-\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir17 end="^\s*\z1\s*$"

syn region shHereDoc matchgroup=shRedir18 fold start="<<\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir18 end="^\z1\s*$"

syn region shHereDoc matchgroup=shRedir19 fold start="<<\\\z([^ \t|]\+\)" matchgroup=shRedir19 end="^\z1\s*$"

@@ -369,8 +369,8 @@ else

syn region shHereDoc matchgroup=shRedir23 start="<<-\s*'\z([^ \t|]\+\)'" matchgroup=shRedir23 end="^\s*\z1\s*$"

syn region shHereDoc matchgroup=shRedir24 start="<<\s*'\z([^ \t|]\+\)'" matchgroup=shRedir24 end="^\z1\s*$"

syn region shHereDoc matchgroup=shRedir25 start="<<-\s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir25 end="^\s*\z1\s*$"

- syn region shHereDoc matchgroup=shRedir26 start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir26 end="^\z1\s*$"
- syn region shHereDoc matchgroup=shRedir27 start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir27 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir26 start="<<\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir26 end="^\z1\s*$" contains=@shDblQuoteList
+ syn region shHereDoc matchgroup=shRedir27 start="<<-\s*\\\_$\_s*\z([^ \t|]\+\)" matchgroup=shRedir27 end="^\s*\z1\s*$" contains=@shDblQuoteList

syn region shHereDoc matchgroup=shRedir28 start="<<-\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir28 end="^\s*\z1\s*$"

syn region shHereDoc matchgroup=shRedir29 start="<<\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir29 end="^\z1\s*$"

syn region shHereDoc matchgroup=shRedir30 start="<<\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir30 end="^\z1\s*$"

--
1.9.3+fc1~5~gfaddd51

[Felipe Contreras]

Otherwise code such as:

cat <<-\EOF
$foobar
EOF

Is not matched properly, as vim assumes the delimiter is '\EOF', when in
fact it's 'EOF'.

Signed-off-by: Felipe Contreras <felipe.c...@gmail.com>
---

runtime/syntax/sh.vim | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/runtime/syntax/sh.vim b/runtime/syntax/sh.vim
index d9d7606..8caa81f 100644
--- a/runtime/syntax/sh.vim
+++ b/runtime/syntax/sh.vim
@@ -361,6 +361,8 @@ elseif s:sh_fold_heredoc

syn region shHereDoc matchgroup=shRedir17 fold start="<<-\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir17 end="^\s*\z1\s*$"
syn region shHereDoc matchgroup=shRedir18 fold start="<<\s*\\\_$\_s*'\z([^ \t|]\+\)'" matchgroup=shRedir18 end="^\z1\s*$"
syn region shHereDoc matchgroup=shRedir19 fold start="<<\\\z([^ \t|]\+\)" matchgroup=shRedir19 end="^\z1\s*$"

+ syn region shHereDoc matchgroup=shRedir33 fold start="<<-\s*\\\z([^ \t|]\+\)" matchgroup=shRedir33 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir34 fold start="<<-\s*\\\_$\_s*\\\z([^ \t|]\+\)" matchgroup=shRedir34 end="^\s*\z1\s*$"

else
syn region shHereDoc matchgroup=shRedir20 start="<<\s*\\\=\z([^ \t|]\+\)" matchgroup=shRedir20 end="^\z1\s*$" contains=@shDblQuoteList
@@ -376,6 +378,8 @@ else

syn region shHereDoc matchgroup=shRedir30 start="<<\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir30 end="^\z1\s*$"

syn region shHereDoc matchgroup=shRedir31 start="<<-\s*\\\_$\_s*\"\z([^ \t|]\+\)\"" matchgroup=shRedir31 end="^\s*\z1\s*$"
syn region shHereDoc matchgroup=shRedir32 start="<<\\\z([^ \t|]\+\)" matchgroup=shRedir32 end="^\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir35 start="<<-\s*\\\z([^ \t|]\+\)" matchgroup=shRedir35 end="^\s*\z1\s*$"
+ syn region shHereDoc matchgroup=shRedir36 start="<<-\s*\\\_$\_s*\\\z([^ \t|]\+\)" matchgroup=shRedir36 end="^\s*\z1\s*$"
endif

" Here Strings: {{{1
@@ -692,6 +696,10 @@ hi def link shRedir29 shRedir
hi def link shRedir30 shRedir
hi def link shRedir31 shRedir
hi def link shRedir32 shRedir
+hi def link shRedir33 shRedir
+hi def link shRedir34 shRedir
+hi def link shRedir35 shRedir
+hi def link shRedir36 shRedir

" Set Current Syntax: {{{1
" ===================
--
1.9.3+fc1~5~gfaddd51

[Felipe Contreras]

Hello?

Why hasn't this been fixed?

--
Felipe Contreras

[Nikolay Pavlov]

2015-10-15 13:10 GMT+03:00 Felipe Contreras <felipe.c...@gmail.com>:
> Hello?
>
> Why hasn't this been fixed?

You need to CC file maintainer, not just list. Also do not top post.

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Felipe Contreras]

On Thu, Oct 15, 2015 at 5:49 AM, Nikolay Pavlov <zyx...@gmail.com> wrote:
> 2015-10-15 13:10 GMT+03:00 Felipe Contreras <felipe.c...@gmail.com>:
>> Hello?
>>
>> Why hasn't this been fixed?
>
> You need to CC file maintainer, not just list. Also do not top post.

Really? The maintainer is not subscribed?

--
Felipe Contreras

[Nikolay Pavlov]

The rule is that it is maintainer who can fix the file and nobody
else. So you *must* CC it, anybody else will jump in only if
maintainer does not reply (usually in this case whoever fixes the
issue is the new maintainer).

This does not mean he is not subscribed. But there are lots of
messages here in this list and CC’ing highlights specific message.
Also some maintainers maintain many files and thus may miss the
message just because they do not remember about this particular one.

>
> --
> Felipe Contreras

[Felipe Contreras]

On Thu, Oct 15, 2015 at 8:02 AM, Nikolay Pavlov <zyx...@gmail.com> wrote:
> 2015-10-15 14:03 GMT+03:00 Felipe Contreras <felipe.c...@gmail.com>:
>> On Thu, Oct 15, 2015 at 5:49 AM, Nikolay Pavlov <zyx...@gmail.com> wrote:
>>> 2015-10-15 13:10 GMT+03:00 Felipe Contreras <felipe.c...@gmail.com>:
>>>> Hello?
>>>>
>>>> Why hasn't this been fixed?
>>>
>>> You need to CC file maintainer, not just list. Also do not top post.
>>
>> Really? The maintainer is not subscribed?
>
> The rule is that it is maintainer who can fix the file and nobody
> else. So you *must* CC it, anybody else will jump in only if
> maintainer does not reply (usually in this case whoever fixes the
> issue is the new maintainer).

That's an inefficient rule.


--
Felipe Contreras

[Charles Campbell]

Felipe Contreras wrote:
> Hello?
>
> Why hasn't this been fixed?
>

I don't read every message on the list, plus I've been busy lately. As
Nikolay Pavlov mentions, emailing me directly is the best way to get
things into the syntax files I maintain. I suggest that you try the
latest version of syntax/sh.vim, which you can get from
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH. Here
documents have been changed a bit since you made your patches; for
example, shHereDoc15 is the maximum heredoc type, which makes applying
your patches problematic. Any changes one makes needs to pass my syntax
checking tests or, if one or more tests fails, the previous state needs
to be understood as to be in error and the new state as correct.

Regards,
Chip Campbell

[Felipe Contreras]

Five years later and this still doesn't work correctly. No wonder
there's a need for neovim.

--
Felipe Contreras

[Christian Brabandt]

On Do, 13 Jun 2019, Felipe Contreras wrote:

> Five years later and this still doesn't work correctly.

Well, have you contacted the maintainer?

> No wonder there's a need for neovim.

No need to be snarky here. Note that Neovim handles runtime files like
Vim does (because they use mostly the same runtime files). So your
comment is actually wrong.

Best,
Christian
--
Vorwärts immer, rückwärts nimmer.
-- Super Mario
(Marc-Uwe Kling: Falsch zugeordnete Zitate; eigentlich Erich Honecker)

[Felipe Contreras]

I didn't contact the maintainer, it should be responsibility of him/her to be responsive to patches.

His address on the syntax file is wrong anyway.

He eventually replied, years later, not looking at my patches, and he didn't reply to me so I never got that response. He said he didn't read every mail in the mailing list (even though all he needed to do is read the sh syntax mails), presumably implying that he wanted to be CC'ed, but then he doesn't CC me, so the only way I could have read his response is to be constantly checking the mailing list for two years.

And the comment I made was not about the content of the code, certainly not about the content of the sh syntax file, it was about the development **PROCESS**.

The current content of the code is almost irrelevant, as the project with the better development **process** will eventually have better code.

So my comment was true, it's just that you are not listening to what I'm actually saying.

And BTW it was a miracle I saw this mail, as I saw it from the web interface. I'm a member of this group but I don't receive mail from it. I guess there isn't a habit of replying to the person you are actually replying.

I'm not trying to be snarky, I'm just trying to to illuminate the fact that my experience as a random patch contributor has been anything but smooth. I contribute to many projects and rarely do I experience such issues.

[Bram Moolenaar]

Felipe Contreras wrote:

> I didn't contact the maintainer, it should be responsibility of
> him/her to be responsive to patches.

The way Vim runtime file maintenance works is that you report any
problems or possible improvements directly to the maintainer.
If the maintainer does not respond we may look at other ways.

> His address on the syntax file is wrong anyway.

There are instructions how to fix that. But many people don't spot
that, there are better ways to avoid spam these days.

> He eventually replied, years later, not looking at my patches, and he
> didn't reply to me so I never got that response. He said he didn't
> read every mail in the mailing list (even though all he needed to do
> is read the sh syntax mails), presumably implying that he wanted to be
> CC'ed, but then he doesn't CC me, so the only way I could have read
> his response is to be constantly checking the mailing list for two
> years.

That's very slow indeed.

> And the comment I made was not about the content of the code,
> certainly not about the content of the sh syntax file, it was about
> the development **PROCESS**.
>
> The current content of the code is almost irrelevant, as the project
> with the better development **process** will eventually have better
> code.

Every maintainer has the freedom to use his choice of process. Some
have a github project where you can file an issue or pull request, some
just use email. Enforcing a certain way of working will increase the
bureden on maintainers, which for some people is already a bit much.

> So my comment was true, it's just that you are not listening to what
> I'm actually saying.
>
> And BTW it was a miracle I saw this mail, as I saw it from the web
> interface. I'm a member of this group but I don't receive mail from
> it. I guess there isn't a habit of replying to the person you are
> actually replying.

I'm actually CC'ing the sender (and some people don't like getting the
message twice).

> I'm not trying to be snarky, I'm just trying to to illuminate the fact
> that my experience as a random patch contributor has been anything but
> smooth. I contribute to many projects and rarely do I experience such
> issues.

Everbody here is volunteering and we'll have to live with slow responses
and various ways of mainaining runtime files.

--
hundred-and-one symptoms of being an internet addict:
177. You log off of your system because it's time to go to work.

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

On Fri, Jun 14, 2019, 16:25 Bram Moolenaar <Br...@moolenaar.net> wrote:

Every maintainer has the freedom to use his choice of process.  Some
have a github project where you can file an issue or pull request, some
just use email.  Enforcing a certain way of working will increase the
bureden on maintainers, which for some people is already a bit much.

Indeed, that's the maintainer's prerogative, but some processes are more efficient that others.

And what is easier? Ask n number of people to change their ways (contributors), or ask one person? (maintainer).

> So my comment was true, it's just that you are not listening to what
> I'm actually saying.
>
> And BTW it was a miracle I saw this mail, as I saw it from the web
> interface. I'm a member of this group but I don't receive mail from
> it. I guess there isn't a habit of replying to the person you are
> actually replying.

I'm actually CC'ing the sender (and some people don't like getting the
message twice).

That's what I expect to be the normal behavior.

Mailing lists managers allow you to specify if you in particular don't want to receive duplicates, but it seems GoogleGroups doesn't have that option, they just do the sane thing by default.

> I'm not trying to be snarky, I'm just trying to to illuminate the fact
> that my experience as a random patch contributor has been anything but
> smooth. I contribute to many projects and rarely do I experience such
> issues.

Everbody here is volunteering and we'll have to live with slow responses
and various ways of mainaining runtime files.

Sure. Slow responses are one thing, years of delay are another, no response (functionally) is something else, and for the contributions to drop completely flat... That's objectively not good.

Cheers.