Posts Tagged ‘mail’
Combining and printing many emails
June 15th, 2010 at 4:21 pm
I’m often faced with the need to gather up and print out all the email I have on a project at work. I’ve written before about how I organize messages in folders by project—and use MsgFiler to help with that—so the gathering part is taken care of. What about the printing?
Let me first agree with those of you who think printing emails is a huge waste, the kind of thing that clueless old executives have their secretaries do because they’re too “busy” to learn how to use email. But I often don’t have a choice; I need to generate paper copies of the email because those “busy” executives are my clients. (This is why I blog pseudonymously.)
So, how do you print a bunch of selected emails without wasting a lot of time or paper? You could use Mail’s Save As… command from the File menu. That will combine all the selected emails into one RTF or plain text document that you can open in whatever application strikes your fancy and print from there. Unfortunately, the plain text version is kind of ugly and the RTF version goes too far in styling the text.
The gray and blue text won’t print out well on a monochrome printer and won’t photocopy well, either.
A better solution can be found by modifying this old tip at Mac OS X Hints. The tip describes an Automator action that
- Grabs all the selected messages,
- Combines them, and
- Creates a single new Mail message from the combination.
I’ve altered it just a bit, changing the last step from creating a new Mail message to creating a new TextEdit document.
The advantages of this are that all the text is black and the messages are separated by decorative lines, better for printing, photocopying, and reading.
I keep the Combine Messages workflow in my ~/Library/Scripts/Applications/Mail folder, where FastScripts can find it and make it available whenever Mail is the active application.
The font is big enough to still be readable when I print the combined document two-up. Along with duplex printing, this keeps the paper waste to a minimum.
Scheduling to-dos
April 15th, 2010 at 4:01 pm
Geez, it’s been a while since I last posted an original script here, so let’s fix that.
One of the things I miss about OmniFocus is its ability to hide tasks until a given date. The advantage of being able to do this is that you can add the task when it comes to you, but you won’t see it as part of your regular to-do list until the time is ripe. My favorite example is the recurring task of changing my furnace filter, which I do every 3-4 months. I liked how OmniFocus allowed me to enter this task but kept it out of my Next Actions list until a week or so before I was supposed to do it.
TaskPaper, my current to-do-list manager, doesn’t have this feature. TaskPaper’s greatest strength, and the reason I actually use it, is its simplicity, but this is one area where a little complexity would help. Since TaskPaper’s “database” of to-dos is just a simple text file, it’s easy to write scripts that extend its features (like this one), and last week I started planning a script that would automatically add scheduled tasks to my main to-do list. After a bit of thinking, though, I stopped.
Here’s the thing: I’ve never stuck with any particular task managing system, software- or paper-based, for more than a year at a time. As much as I like TaskPaper now, why should I assume I’ll still be using it a year from now? Why should I invest the time in writing a script that will be used for only a small percentage of my to-dos and may never be used after Christmas? I decided to go for a longer-lasting solution.
I’ve been using iCal and Mail continuously for over five years, ever since returning to the Mac from Linux. If I’m at my computer, they’re running. So the most robust system, it seemed, would be one that emails me a reminder when it’s time to add a task to my to-do list. Although this system won’t add the entry automatically, it will work no matter what task manager I use.
First, I created a new iCal calendar called tasks.
Every entry in this calendar will be an item that should go into my to-do list on the specified date. I keep this calendar unchecked, and therefore invisible, except when entering a scheduled task, because these aren’t part of what David Allen calls the “hard landscape,” and so, according to GTD orthodoxy, shouldn’t be in my calendar at all. In fact, I don’t consider the tasks entries as part of my calendar, per se—they’re merely using iCal as a convenient mechanism for running scripts on a schedule.
Here’s my entry for replacing the furnace filter.
It’s a recurring event that appears quarterly on the morning of the first day of the month. The summary, “Change furnace filter,” is the task to be added to my to-do list on that day. When the scheduled time arrives, it runs an AppleScript called Email Scheduled Task:
1: set rightNow to current date
2: set fiveMinutesAgo to rightNow - 5 * minutes
3: set fiveMinutesFromNow to rightNow + 5 * minutes
4:
5: tell application "iCal"
6: set theEvents to every event of calendar "tasks" whose start date comes after fiveMinutesAgo and start date comes before fiveMinutesFromNow
7: set theTask to the summary of item 1 of theEvents
8: end tell
9:
10: tell application "Mail"
11: set theMessage to make new outgoing message with properties {visible:true, subject:"Scheduled Task", content:theTask}
12: tell theMessage
13: make new to recipient at end of to recipients with properties {name:"Dr. Drang", address:"user@example.com"}
14: end tell
15: send theMessage
16: end tell
The script does three things:
- It gets the current time and sets up a ten-minute window around it.
- It looks through the tasks calendar for entries within that window of time and gets the summary of the first one.
- It sends an email to me with that summary as the content and “Scheduled Task” as the subject.
A time window of some sort was needed because the script’s call to current date will almost certainly not be exactly equal to the entry’s start date. A window as wide as ten minutes is probably unnecessary, but I was feeling generous. As long as I don’t create entries with overlapping windows—a very easy restriction to satisfy—the theEvents list returned by Line 6 will have just one item, and therefore Line 7 will grab only the task that triggered the script.
(If you’re wondering why there isn’t an easier way to get the event that triggered the script, join the club. I couldn’t find one.)
I learned how to do the date math in Lines 2 and 3 from the AppleScript Language Guide and how to set up and send an email message from this MacTech article.
On the morning of July 1, the message “Change furnace filter” will be in my inbox when I get to work. I’ll select and copy the content text and paste it into TaskPaper (or whatever I’m using by then). Presumably, I’ll change the filter shortly thereafter and scratch it off my list. Repeat on October 1, January 1, etc.
Never can say goodbye
April 12th, 2010 at 9:41 am
Back in January, I wrote this little script for determining which process is preventing me from emptying my Trash. You know the problem: you try to empty your Trash and you get an error message telling you that file xxx can’t be deleted because it’s in use. My script, called trash-users, invokes the system-supplied lsof command to tell you which process won’t let the file go.
I’ve used trash-users a handful of times in the past few months, and in every case, the problem was Mail not allowing me to delete a file that I had attached to an email. These were files I needed to forward along to someone but didn’t need to retain. For some reason, even well after the messages were sent, Mail wouldn’t release the file for deletion.
Not every attachment I throw in the Trash gets hung up this way, so it’s not an easily reproducible bug, but I’ve submitted it to Apple anyway.
Alternate titles considered for this post were “You Keep Me Hanging On” and “Please Mr. Postman.” Mail bugs must have an affinity for Motown.
Update 4/13/10
Apple has classified this bug as a duplicate and is supposedly investigating/working on it. Based on the original bug number, I would guess this was first reported back in 2008 or so. Doesn’t seem to be a high priority.