add a convert_space_hack flag, which turns N spaces into N-1  s and a

	* mail-format.c (text_to_html): add a convert_space_hack flag,
	which turns N spaces into N-1  s and a space.
	(handle_text_plain): Check for "format=flowed" in the
	Content-Type.
	(handle_text_plain_flowed): Spinoff of handle_text_plain to deal
	with RFC 2646 flowed text. (All the examples I can find of it
	are generated by Eudora, but it's a pretty cool idea that ought
	to be used more widely.)

svn path=/trunk/; revision=2618

1 files changed, 32 insertions, 23 deletions

diff --git a/mail/ChangeLog b/mail/ChangeLog
index 0edb047b14..f9b746de5e 100644
--- a/mail/ChangeLog
+++ b/mail/ChangeLog
@@ -1,17 +1,18 @@
 2000-04-25  Dan Winship  <danw@helixcode.com>
 
-	* mail-format.c, mail-display.c: Now that we're not limited to
-	a single GtkHTML for the display, there's no reason to embed
-	Bonobo objects for unrecognized content-types in GtkHTML rather
-	than embedded them into the vbox directly. So do that.
+	* mail-display.c, mail-format.c: Redo large chunks of this. The
+	mail display now consists of a vbox in a scrolled window, in which
+	we put multiple GtkHTML objects. This means broken HTML in one
+	part can't corrupt other parts. The headers now scroll with the
+	body. Unrecognized attachments look prettier, but still don't do
+	anything, and will probably be changed later. We can also now
+	display nested message/rfc822 parts and multipart/alternatives
+	with multipart subparts. Oh, and text/{richtext,enriched}, since
+	we had all these ancient sample messages that use it and the lack
+	of support annoyed me. :)
 
-	Meanwhile, fix up the handler-selection code so that we can
-	declare which built-in handlers are more desirable than external
-	handlers and which are less. (Of course, eventually we'll want
-	this to be customizable.) Add some cleverness to
-	handle_multipart_alternative as well so it doesn't accept an
-	alternative which we can display generically over one we can
-	display specifically.
+	Bonobo embeddables are broken right now, but I don't think that's
+	my fault.
 
 	* mail-format.c (reply_body): Fix some bugs that crept into reply
 	generation. This needs a lot more work to deal correctly with
@@ -25,19 +26,27 @@
 	usually.
 	(reply_body): Make this deal better with multiparts.
 
-	* mail-display.c, mail-format.c: Redo large chunks of this. The
-	mail display now consists of a vbox in a scrolled window, in which
-	we put multiple GtkHTML objects. This means broken HTML in one
-	part can't corrupt other parts. The headers now scroll with the
-	body. Unrecognized attachments look prettier, but still don't do
-	anything, and will probably be changed later. We can also now
-	display nested message/rfc822 parts and multipart/alternatives
-	with multipart subparts. Oh, and text/{richtext,enriched}, since
-	we had all these ancient sample messages that use it and the lack
-	of support annoyed me. :)
+	* mail-format.c, mail-display.c: Now that we're not limited to
+	a single GtkHTML for the display, there's no reason to embed
+	Bonobo objects for unrecognized content-types in GtkHTML rather
+	than embedded them into the vbox directly. So do that.
 
-	Bonobo embeddables are broken right now, but I don't think that's
-	my fault.
+	Meanwhile, fix up the handler-selection code so that we can
+	declare which built-in handlers are more desirable than external
+	handlers and which are less. (Of course, eventually we'll want
+	this to be customizable.) Add some cleverness to
+	handle_multipart_alternative as well so it doesn't accept an
+	alternative which we can display generically over one we can
+	display specifically.
+
+	* mail-format.c (text_to_html): add a convert_space_hack flag,
+	which turns N spaces into N-1 &nbsp;s and a space.
+	(handle_text_plain): Check for "format=flowed" in the
+	Content-Type.
+	(handle_text_plain_flowed): Spinoff of handle_text_plain to deal
+	with RFC 2646 flowed text. (All the examples I can find of it
+	are generated by Eudora, but it's a pretty cool idea that ought
+	to be used more widely.)
 
 2000-04-23  Dan Winship  <danw@helixcode.com>