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

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

On Fri, Apr 15, 2011 at 5:30 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Apr 15, 2011 at 12:43:08AM +0200, Erik Faye-Lund wrote:
>
>> >> 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.
>
> Won't that be a regression for people who already know that we take
> things literally and are manually quoting and/or rfc2047-encoding the
> contents?

Yes. But won't that always be the case when someone depends on buggy behavior?

Besides, send-email takes interprets it's --to and --cc arguments as
well as sendemail.to and sendemail.cc config options literally (i.e
quoting if needed without any attempts on unquoting first). IMO having
two closely related programs with similar options that behave
different in border-cases is pretty ugly. ESPECIALLY when one of them
has a habit of forwarding unknown options to the other, like
send-email does...