Re: [BUG] format-patch does not wrap From-field after author name

[Erik Faye-Lund <kusmabite@gmail.com>]

On Fri, Apr 15, 2011 at 12:29 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Apr 15, 2011 at 12:21:24AM +0200, Erik Faye-Lund wrote:
>
>> >> True. But since the fix is as simple as it is, perhaps it's worth it
>> >> just for the clean conscience?
>> >
>> > Fair enough. Patch to follow.
>> >
>>
>> Thinking about it a bit more, I'm getting a bit more unsure:
>> - The 78-limit is about user-interfaces, not protocol robustness.
>
> True. In theory we should also be limiting to avoid the 998-character
> hard protocol limit, but that is getting ridiculously unlikely.

I think that's over in my definition of "insanity land", yeah :)

>> - Since send-email unwraps the line and does not re-wrap it, even if
>> we have a name like this it's likely that the work gets undone right
>> away.
>
> Not everybody uses send-email. So you are also helping MUAs which
> consume the output of format-patch.

Good point.

> That being said, I doubt that this will make a difference to anybody.
> The real reason that we put wrapping into add_rfc2047 was for subjects,
> which _do_ get long.

Absolutely.

>> - So that means that send-email should probably also be fixed. But now
>> I'm wondering if we've crossed the point where this will just lead to
>> less obvious code for very little gain.
>
> It is ugly code.
>
> I'm just as happy if we drop it.

OK, then I'll try to forget about this issue for now. Sorry for troubling you.

>> > Because it means we have to _parse_ those
>> > headers and understand which part is a name and which is an address.
>>
>> That part is surprisingly easy: If it contains a '<', then it's on the form
>> "Foo Bar Baz <foo@bar.baz>". If not, it's "foo@bar.baz" (assuming it's
>> UTF-8 encoded rfc5322 mailbox'es we assume, which would make the most
>> sense to me)
>
> What about:
>
>  "Foo \"The Bar\" Baz" <foo@example.com>
>
> or
>
>  Foo "The Bar" Baz <foo@example.com>
>
> or
>
>  Foo (The Bar) Baz <foo@example.com>
>
> I.e., are we taking rfc822-style addresses, or are we taking something
> that looks vaguely like an email address, and just treating everything
> left of "<" as literal?

I was just thinking of interpreting everything left of '<' literally
and encode it (if needed). Currently, we interpret the entire string
literally, encoding the name would an improvement.