On Fri, Apr 15, 2011 at 10:32:27AM +0200, Erik Faye-Lund wrote: > >> 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? I guess I don't see the current behavior as necessarily buggy, just sub-optimal. I can imagine people have worked around it by embedding rfc2047-encoded content manually. But I admit I don't really care that much, and I don't know what common use is. Grepping the list archives didn't turn up anything useful. > 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... Yeah, it would be nice to resolve that inconsistency. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html