[PATCH] parser: remove in-reply-to/references comments

[Raxel Gutierrez]

Thanks for the feedback! I have enough information to write a v2 now,
but I'm focusing on adding new functionality to change state in
Patchwork. I'll likely be able to write v2 within the next 2 weeks.

On Thu, Jun 24, 2021 at 2:52 PM Emily Shaffer <emilyshaffer at google.com> wrote:
> Hm, does the nesting level of the comments really matter? Or is the
> issue that they may be multiline?
>
> That is - it's pretty trivial to write a regex to match
> (foo(bar)baz((quot)meh)), as long as you don't actually care about the
> semantics of the nesting.

There are odd examples
(https://datatracker.ietf.org/doc/html/rfc2822#page-47) where nesting
can occur.

> I *think* this is the bit that's making it not support nesting.
> "Match anything besides another open- or close-paren".
>
> https://docs.python.org/3/library/re.html tells me that Python treats
> '*' as greedy by default, so wouldn't "\(.*\)" handle nested comments?
> Or is there an issue that you can have more that one, e.g.
>
>   In-Reply-To: (danica's mail) abcd1-40-8d at mail.google.com (from gnus)
>
> in which case greedy-matching would also obliterate the actual
> message-id?

I believe multiple comments are possible, especially in the context of
references where parentheses could be attached to separate
message-ids. So, I think message-ids would be cut out in those cases
by  "\(.*\)".

> This actually brings to mind that I'd like to see an example of one such
> problematic line in the commit message, if you've got one handy.

My commit message references the spec for an example of an In-Reply-To
field being problematic because of a comment.

> Hum. Is there a test suite we can add a regression test to for this
> specific kind of line format?

I will be working on adding tests for v2. Luckily, what to consider
for a comment was still being addressed :)