Nup, that file doesn't exist, and it was totally rewritten anyway.
On Sat, 2004-05-22 at 21:52 -0400, Benjamin Kahn wrote:
I wrote a patch to do this once, but it was written for a /very/ old version of Evolution. It probably doesn't work and probably never did... :) Anyway, here it is: --- mail/mail-format.c Thu Nov 8 15:39:36 2001 +++ mail/mail-format.c.orig Sat Nov 10 16:55:31 2001 @@ -1971,7 +1971,7 @@ multipart = CAMEL_MULTIPART (wrapper); - mime_part = find_preferred_alternative (multipart, FALSE); + mime_part = find_preferred_alternative (multipart, TRUE); if (mime_part) return format_mime_part (mime_part, md); else I'd be surprised if it even still applies. On Sun, 2004-05-23 at 08:59 +0800, Not Zed wrote: > On Sat, 2004-05-22 at 21:03 +0200, Eric Schaefer wrote: > > On Sat, 2004-05-22 at 20:05, Andre Klapper wrote: > > > if i remember correctly, this has not been implemented since the rfc > > > says that a message which has been sent both as html and plaintext > > > should be displayed in html (correct me if i'm wrong). > This is not quite correct. > > So why would you want to send the plaintext along with the html anyways? > Pretty simple, because not all clients can display html properly. > Read the relevent sections of rfc 2046 if you need more detailed > justification. Its to do with interoperability and open extensibility > of the format. > > I dont think there is a RFC that deals with overriding user preferences > > for mail display (mail encoding is another chapter). If I want all my > > mail displayed as rot39 encoded plaintext, blue text on red background, > > the MUA ought to display it that way. > I would disagree. Since that would be a pointless feature to add; it > would even be useless to you since it isn't a standard representation > of a typical human language. > > Back to the topic, "multipart/alternative" is pretty simple, it > provides the ability to send alternate and richer forms of email in > ways that can still be ready by older or less featureful clients. The > standard says 'display the last part you know how to handle', and for > senders 'send the data in order from most to least information lost'. > > So we take the simplest approach - we follow the spec. Evolution is a > html emailer, it runs in a grpaphical environment, doing some > artificial feature limitation as a user preferences doesn't have a lot > of use. And what are we supposed to do if we only get text/html with > no plain alternative? Just display it as an attachment? > > Its not even that hard to do, probably a few lines of commented out > code to make out evo is too dumb to know about text/html, i think, > although it always tries to fallback for text/ types so it might need > more code. > > But, it just doesn't seem that useful. > > If someone had really felt that strongly about it, they might've > written a patch, but nobody has. > > > Michael Zucchi > <[EMAIL PROTECTED]> > > Ximian Evolution and > Free Software Developer > > > Novell, Inc.
|
<<attachment: zed-48.small.jpg>>
