Re: [PATCH] send-email: handle adjacent RFC 2047-encoded words properly

From: Jeff King <peff@peff.net>
Date: Nov 24, 2014, 23:03 UTC
Message-ID: <20141124230346.GA10064@peff.net>
In-Reply-To: <op.xpudh8c3nngjn5@freezie>

On Mon, Nov 24, 2014 at 09:26:22PM +0300, Роман Донченко wrote:

Show 5 quoted lines

> Yeah, I did realize that token is more restrictive than encoded-text, but I
> didn't want to stray too far from the subject line of the patch. What I'll
> probably do is split the patch into two, one for regex tweaking and one for
> multiple-word handling. And yeah, I'll try to make the two functions use the
> same regexes.

Thanks, I think that sounds like a good plan.

Show 12 quoted lines

> >For your definition of encoded-text, RFC 2047 says:
> >
> >     encoded-text = 1*<Any printable ASCII character other than "?"
> >                          or SPACE>
> >
> >It looks like you pulled the definition of $et from is_rfc2047_quoted,
> >but I am not clear on where that original came from (it is from a3a8262,
> >but that commit message does not explain the regex).
> 
> No, it's actually an independent discovery. :-) I don't think it needs
> explanation, though - it's just a character class with two ranges covering
> every printable character but the question mark.

And now it is my turn to hang my head in shame. I viewed that as a set of characters, rather than ranges. The "-" just blended into the mass of punctuation, and I mistook the "!" for negation.

I wonder if it would be more readable as:

  [\x21-\x3e\x40-\x7e]

or something. I guess perl even has classes pre-made for "printable ascii". I dunno. It may be OK as-is, too, and I just need to read more carefully. :)

Show 8 quoted lines

> >Also, I note that we handle 'q'-style encodings here, but not 'b'. I
> >wonder if it is worth adding that in while we are in the area (it is not
> >a big deal if you always send-email git-generated patches, as we never
> >generate it).
> 
> I could add "b" decoding, but since format-patch never generates "b"
> encodings, testing would be a problem. And I'd rather not do it without any
> tests.

I think you could include some literal fixtures in the test suite (t5100 already does this for mailinfo). But I don't think handling 'b' is a requirement here. It's really orthogonal to your patches, and nobody has actually asked for it, so I don't mind leaving it for another day.

-Peff