On 14 Aug 2014, at 7:11, Benny Kjær Nielsen wrote:
On 13 Aug 2014, at 20:52, Bill Cole wrote:
I expect Benny will give me a proper slapping if this is
substantially wrong, but I think this is worth sharing since I wasted
a few hours trying to find a better fix for what is probably the
result of a scale-sensitive bug.
I'm sorry you had to spend time on this. I know there is a bug
somewhere in this system, but I don't know what triggers it. Under
certain circumstances MailMate starts to ignore changes to mailbox
related display settings.
I have a vague hypothesis based on the fact that my attempts to do
targeted pruning of the giant MmMailboxRelatedStates dict yielded
erratic results and small variances in what MM left in it after
quitting. Across 16 snapshots, 249 mailboxes had entries in all, 261
different mailboxes had entries in at least one, and all contained 260
or 261 entries. Maybe some array of entries uses an 8-bit index? Seems
unlikely, but only you could figure that out.
Your reset-trick is correct and should be safe to use except for the
loss of settings of course:
defaults delete com.freron.MailMate MmMailboxRelatedStates
Let me know if you find a way to get MailMate back into the buggy
state. (There is a possibility that this is only seen by long time
users with old settings files — in other words, it might not be
reproducible after the fix above.)
Long time users or perhaps users who have large numbers of mailboxes.
It seems like that pile of per-mailbox settings objects must grow almost
strictly monotonically, as there's no obvious way to fully default a
mailbox and do away with the need for its specific settings. Without a
dedicated GC cycle to minimize it, a bloated & broken
MmMailboxRelatedStates may be inevitable for anyone with a large mailbox
count.
_______________________________________________
mailmate mailing list
[email protected]
http://lists.freron.com/listinfo/mailmate
