February 19, 2014 at 8:52 PM by Dr. Drang
This is a followup to my Mavericks Mail post of a couple of days ago. I think I have a better understanding of one of the problems I was having and a workaround for the other.
I can hear many of you saying “Just drop Mail already. It isn’t worth the effort.” You’re probably right, but I’m not in a position right now to switch. Because of the nature of my work, I have a hybrid system in which some of my mail is saved in local mailboxes and some is saved in IMAP mailboxes. Before I move to another mail client, I have to be sure I can export/import all of that structure without losing anything. Maybe that’ll be easy, maybe it won’t, but to be on the safe side, I don’t want to start the migration until my work schedule is a little more open than it is right now.
There’s also the issue of which client to switch to. I mentioned MailMate in the earlier post, but several friends on Twitter have recommended Airmail. And I should probably look into Postbox, too. Whichever I choose, it isn’t going to be a drop-in replacement for Mail. And wouldn’t it be wonderful if Apple fixed Mail and made it so I don’t have to decide?
As for the problems I’ve been having with Mail, let’s start with an update on searching. Many of you suggested that the problem was with Spotlight and that a reindex of its database might be a solution. I think that’s exactly right, and I kind of thought that running the the post) would do just that. Apparently not, although it may have started the reindexing process.command (which I mentioned in the update at the bottom of
After posting the update Monday morning, my disk chitter-chattered for about an hour. Activity Monitor told me one of the
md* processes was running all that time, not taking up much CPU time, but definitely exercising the read/write heads. As best I can tell, searching in Mail has worked correctly since then.
I’m willing to accept a fair amount of the blame for this. The clearly incorrect search results I was getting should have prompted me to think of Spotlight. I have only two things to say in my defense:
- I almost never use Spotlight proper, by which I mean the thing in the menubar. If I use it more than ten times a year, I’d be greatly surprised. I’m more comfortable using
ackto search for words in text files, and my world is almost entirely text files. So Spotlight just isn’t something that comes to mind, and I haven’t had enough experience with it to immediately recognize the signs when it’s gone flaky.
- Apple seemingly provides no automatic Spotlight diagnosis. If you don’t know your search results are incomplete, what would inspire you to reindex your drive? Why don’t Apple’s set of system
launchdprocesses keep Spotlight in tune or a least warn you when it’s out of whack?
applescript: 1: tell application "System Events" 2: tell process "Mail" 3: tell menu bar 1 4: tell menu bar item "Mailbox" 5: tell menu "Mailbox" 6: click menu item "Take All Accounts Offline" 7: delay 2 8: click menu item "Get New Mail" 9: --say "reset" 10: end tell 11: end tell 12: end tell 13: end tell 14: end tell
The two-second delay in Line 7 came after some experimentation—with no delay, the “Get New Mail” command wouldn’t work.
The AppleScript is named
Reset Mail.scpt, and it’s stored in
~/Library/Scripts/Applications/Mail which makes it available to FastScripts if I want to run it manually.
Mostly, though, I want it to be run periodically by
launchd. So I created this launch agent plist file,
xml: 1: <?xml version="1.0" encoding="UTF-8"?> 2: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 3: <plist version="1.0"> 4: <dict> 5: <key>Disabled</key> 6: <false/> 7: <key>Label</key> 8: <string>com.leancrew.ResetMail</string> 9: <key>ProgramArguments</key> 10: <array> 11: <string>/usr/bin/osascript</string> 12: <string>/Users/drang/Library/Scripts/Applications/Mail/Reset Mail.scpt</string> 13: </array> 14: <key>StartInterval</key> 15: <integer>600</integer> 16: </dict> 17: </plist>
com.leancrew.ResetMail.plist, and saved it in
~/Library/LaunchAgents. Items in that folder are supposed to get loaded into
launchd when you log in. You can also force an agent to load and start with these commands from the Terminal:
launchctl load ~/Library/LaunchAgents/com.leancrew.ResetMail.plist launchctl start com.leancrew.ResetMail
The best quick introduction to
launchctl—all killer, no filler—is this post by Nathan Grigg. I return to it every time I need a refresher, which is basically every time I need to use
A few words on these files:
- The commented out Line 9 in the AppleScript is a leftover from the debugging process. I used that line in the early stages of development to make sure
launchdwas running the script when it was supposed to. I decided to leave it there, inactive, in case I need to debug again in the future.
- The plist file will need some editing if you want to use on your computer. You could change the label string in Line 8, but you don’t need to. You definitely need to change the path to the AppleScript in Line 12 to wherever you keep
Reset Mail.scpt. Line 15 tells
launchdto run the script every 10 minutes (600 seconds); change it to whatever feels comfortable to you.
Whenever I get around to switching mail clients, I’ll have to remember to tell
launchd to stop running the script. This will stop it immediately:
launchctl stop com.leancrew.ResetMail launchctl unload ~/Library/LaunchAgents/com.leancrew.RestMail.plist
I think I can leave the plist file where it is if I change the Disabled setting in Line 6 from
<true/>, or maybe I’ll have to use the
-w option with
launchctl unload. Most likely, though, I’ll just move the file out of the
LaunchAgents folder so there’s no chance of it loading the next time I log in.