Cool, Jecel!  Be sure to send your Celeste patches to Giovanni, and your
IRC patches to Frank, so they can consider including them in the next
release.

I have a few comments about the Celeste patches, even without seeing the
code.


> To deal with badly formed emails:
> 
> - patched #digitValue: (Unicode class and EnodedCharSet class) to accept
> lower case letters because some emails had this in headers
> 
> - patched #mimeDecode (RFC2047MimeConverter) to not go crazy on a bad
> sequence

Sounds excellent, on both counts, though I'm not familiar with this
particular part of the code.


> - patched #parts (MIMEDocument) to deal with bad separators
> 

Do you mean MIMEDocument, or MailMessage?  If you meant MailMessage,
then bravo!  If you meant MIMEDocument, then please let's not keep
patching this method, but instead try to get rid of it.  Its own comment
is begging for the misery to end:

	"Return the parts of this message.  There is a far more reliable
implementation of parts in MailMessage, but for now we are continuing to
use this implementation"

The MIMEDocument version doesn't *really* know what the separator is,
and instead has to guess.  Further, I can't think of a reason that a
MIMEDocument would need to be asked for its parts directly; if it's
multi-part, then its a mail message, and thus the MailMessage object
ought to be handy.


> To load the database from an older version I forced some files to open
> as a StandardFileStream.

Certain minds think alike!  I sent such a patch to Giovani already. 
Some day, it would be nice to fix Celeste up to use international
characters, but for now this at least keeps it working.


> To deal with international characters in general, removed #isoToSqueak
> and #squeakToIso from all methods in Celeste, CelesteComposition and
> MailMessage. The ones in CelesteComposition were already causing
> problems in Squeak 3.7 since they were being applied twice.

Ummm, are you sure these are all correct?  The on-disk messages file
should be in MacRoman for compatibility's sake.  Is Squeak now switching
to latin-1 encodings internally?  If so, then yes, some of these sends
should go away.  But step carefully.  Be sure to test with a
pre-existing email database that has MacRoman 8-bit characters in it.

Another thing to think about, is that we probably want to switch to
unicode mail databases in the long run.  That will be yet another format
change.  I can live with one format change even if it breaks my existing
files, but it would be nice to do that as rairly as possible.


> To deal with different charsets added some stuff to #from: in
> MailMessage. Had to add workaround in #formattedText in Mail message
> (described in Mantis) to replace large Unicode characters with $?.

Yeah.  Well hopefully the Squeak text support will get fixed before
long, so that we do not need this workaround.


> Something I have done messed up HTML rendering, which was working
> before.

Ack!  Not that I love HTML emails, but it should still work....  Maybe
look in #bodyTextFormatted and see if you see anything funny looking?


Lex