Subject: [Jsonpath] PR regarding selectors ...

From: Stefan Gössner <[email-masked]>
Date: Thu, 10 Jun 2021 19:17:32 +0200

... had a hard time with this PR. Lost all changes ... luckily could 
recover them, thanks git.

PR finally failed ... help needed.

thanks
--
sg

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jun 2021 20:21:44 +0200

On 10. Jun 2021, at 19:17, Stefan Gössner <[email-masked]> wrote:
> 
> ... had a hard time with this PR. Lost all changes ... luckily could recover them, thanks git.
> 

I fixed the YAML nit in PR #99.

Unfortunately, the build is confused about branches; I need to find out why.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jun 2021 20:36:31 +0200

Fixed in #99 (a few syntax nits: numbered sections cannot follow unnumbered sections, attribute lists for table must stick to the table.  There also was trailing whitespace.)

I couldn’t put this back in #98 because my tool really don’t like using the branch name “main” for pull requests; I didn’t know that.

(And the makefile still is confused about the default branch, but that seems to be innocuous.)

Grüße, Carsten

> On 10. Jun 2021, at 20:21, Carsten Bormann <[email-masked]> wrote:
> 
> On 10. Jun 2021, at 19:17, Stefan Gössner <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Stefan Gössner <[email-masked]>
Date: Fri, 11 Jun 2021 07:31:10 +0200

Thanks a lot Carsten for helping here out.

> Fixed in #99 (a few syntax nits: numbered sections cannot follow 
> unnumbered sections,
oh well ...

> attribute lists for table must stick to the table.

but then they are displayed as the last table row ... ok, if it's necessary.

> There also was trailing whitespace.)

hmm .. . this is important to avoid.
>
> I couldn’t put this back in #98 because my tool really don’t like 
> using the branch name “main” for pull requests; I didn’t know that.
>
>> On 10. Jun 2021, at 20:21, Carsten Bormann <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> [email-masked] <mailto:[email-masked]>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virenfrei. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Jun 2021 13:46:25 -0700

James and I think we should discuss this contribution at our interim on
Tuesday.  Stefan, as several people have pointed out, that's a pretty
substantial package of changes.  Could we ask you to lead that part of the
agenda, select a few key points suitable for the WG to progress while we're
online together and introduce them?  [I'm sympathetic to the suggestion
that you decompose the PR into a few smaller ones, but that's not a
requirement.]

On Thu, Jun 10, 2021 at 10:31 PM Stefan Gössner <[email-masked]> wrote:

> I couldn’t put this back in #98 because my tool really don’t like using
> the branch name “main” for pull requests; I didn’t know that.
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virenfrei.
> www.avg.com
> <#m_5061528231431129916_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> --
> Jsonpath mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jun 2021 23:04:43 +0200

>> hmm .. . this is important to avoid.

Unfortunately, giving a meaning to trailing whitespace is one of the big blunders that John Gruber made when defining markdown.

Kramdown-rfc plays along, but the whole thing is so error-prone that Martin Thomson created a commit hook that stops you from committing changes that introduce trailing whitespace.

Which maybe is a reasonable thing to do, but it creates an interesting failure situation:
Somebody manages to sneak in a commit that does create trailing whitespace.
If somebody tries to edit the document updated with that commit, they can’t commit their changes because the commit hook doesn’t let them commit.

Of course, modern editors have easy ways to get rid of trailing whitespace (M-x delete-trailing-whitespace RET in emacs), but the next committer
(1) first has to diagnose the problem
(2) needs to find that command that they may not need too often
(3) litters their PR with all those whitespace changes because they'd lose the changes in the working copy otherwise.

I don’t know a way to avoid trailing whitespace that doesn’t have that problem, or I would already have suggested that change to Martin.

TL;DR, yes, let’s please avoid committing trailing whitespace.

Grüße, Carsten

---

From: Glyn Normington <[email-masked]>
Date: Sat, 12 Jun 2021 07:56:15 +0100

Agreed. That's one of the reasons we introduced an .editorconfig file,
which contains the setting:

trim_trailing_whitespace = true

To find out how to apply .editorconfig to your editor or IDE, please
see CONTRIBUTING.md.

---

From: Stefan Gössner <[email-masked]>
Date: Sat, 12 Jun 2021 18:32:39 +0200

I am very well aware about meaning of trailing whitespace in Markdown. 
But what is new to me is, that whitespace

* in metadata section (YAML)
* in code section

needs to be avoided too. Ok, now I know.
--
sg

Am 11.06.2021 um 23:04 schrieb Carsten Bormann:
> On 11. Jun 2021, at 07:31, Stefan Gössner <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
> Unfortunately, giving a meaning to trailing whitespace is one of the 
> big blunders that John Gruber made when defining markdown.
>
> Kramdown-rfc plays along, but the whole thing is so error-prone that 
> Martin Thomson created a commit hook that stops you from committing 
> changes that introduce trailing whitespace.
>
> If somebody tries to edit the document updated with that commit, they 
> can’t commit their changes because the commit hook doesn’t let them 
> commit.
>
> Of course, modern editors have easy ways to get rid of trailing 
> whitespace (M-x delete-trailing-whitespace RET in emacs), but the next 
> committer
> (3) litters their PR with all those whitespace changes because they'd 
> lose the changes in the working copy otherwise.
>
> I don’t know a way to avoid trailing whitespace that doesn’t have that 
> problem, or I would already have suggested that change to Martin.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Jun 2021 09:37:27 +1000

> changes that introduce trailing whitespace.

`make update` will ensure you have the hook enabled.

You can commit without the hook using `git commit -n ...` and follow with a pure whitespace change.  I try to do that as much as possible.

> TL;DR, yes, let’s please avoid committing trailing whitespace.

Yes.