On 27 Aug 2015, at 22:27, Michael Tsai wrote:
On Aug 27, 2015, at 3:03 PM, Muster Hans <[email protected]> wrote:
I tried both the EF bundle method and dragging to the Finder. The EF
bundle
method was painfully slow, though that was not helped by EagleFiler
generating
a notification for every single message. I tried turning that off in
System Preferences / Notifications but they still kept on coming.
I've just
discovered an Esoteric Preference for that, but the documentation
doesn't seem
to match the behaviour I saw.
The MailMate bundle is probably always going to be slower than
drag-and-drop because it compiles and runs a separate AppleScript
command for each message. This is also why you get a notification per
message rather than one for the batch.
Understood.
You can adjust in System Preferences how notifications are displayed,
but not whether they are posted or recorded. It may be that the system
kept displaying notifications after you had turned it off because it
was still processing old notifications.
That could indeed be the case.
To stop the notifications entirely, you would need to use the
DisableNotificationCenter esoteric preference:
<http://c-command.com/eaglefiler/help/esoteric-preferences>
Done, and I will monitor this.
If you have further questions about this, please feel free to contact
me at <[email protected]>.
In contrast, 3,800 messages went into EF via dragging in about 6
minutes.
It's taking 6 minutes because there are so many separate files. If you
import from Apple Mail, EagleFiler would generate a mbox file and do
the import in 30 seconds or so. My guess is that the new MailMate
Export bundle would work similarly.
I was actually quite pleased with 6 minutes. It's not something I plan
on doing very often.
However, I ran into a real show stopper for me - EF doesn't support
UTF-8.
From "DefaultMessageEncoding" at
http://c-command.com/eaglefiler/manual#esoteric-preferences
"When a message doesn’t specify which text encoding it uses,
EagleFiler has
to guess. An incorrect guess may cause the message to display using
strange
accents or garbage characters. By default EagleFiler guesses
MacRoman, but
you can change it to guess ISO Latin 1 instead."
EagleFiler does support UTF-8. For example, the message that you just
sent declares itself as:
Content-Type: text/plain; charset="utf-8"; Format="flowed"
and the Unicode characters at the end display properly in EagleFiler
(as does "Grüsse").
The DefaultMessageEncoding esoteric preference only applies when the
message (improperly) uses non-ASCII characters without specifying what
encoding they are in. I don't think I've ever seen a message that did
this using UTF-8. Generally, it is older mail clients that would,
e.g., send the message as MacRoman with no explicit encoding, so that
it would only display properly if the client knew to assume that it
was in MacRoman. This was back when apps didn't support Unicode, so it
shouldn't be an issue with modern mail clients. However, if you do
come across a message that is using UTF-8 without specifying it, you
could set the esoteric preference accordingly:
<x-eaglefiler://default?k=DefaultMessageEncoding&v=utf-8>
This resolves a non-mail related artefact I have been seeing, so thanks
for that - unfortunately this isn't in the current EagleFiler manual.
I have a load of mails in German where each and every accented
character
gets mangled by EF. E.g. "Freundliche Grüsse" (~=Regards) displays
in EF as
"Freundliche Gr=FCsse", and it's a similar disaster with other
accented
characters.
Please send one of the problem .eml files to
<[email protected]> so that I can look into this.
Will do, though I've now stumbled across a different problem. It
appears that any mail containing Unicode characters gets encoded.
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Expected behaviour when there are still 7 bit mail gateways out there,
but when imported into EagleFiler I just see the encoded block.
Thanks very much for your prompt response. It is much appreciated.
_______________________________________________
mailmate mailing list
[email protected]
http://lists.freron.com/listinfo/mailmate
