Re: [BUG] format-patch does not wrap From-field after author name
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- Apr 14, 2011, 22:43 UTC
- Message-ID
- <BANLkTim0Q+RaExss+U3m-=CHT6Jd1jc56Q@mail.gmail.com>
- In-Reply-To
- <20110414222940.GA19389@sigill.intra.peff.net>
On Fri, Apr 15, 2011 at 12:29 AM, Jeff King <peff@peff.net> wrote:
Show 13 quoted lines
> 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 :)
Show 6 quoted lines
>> - 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.
Show 7 quoted lines
>> - 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.
Show 23 quoted lines
>> > 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.