A while ago, I wrote about a new bug that I am experiencing in Lion’s Mail, where any sent message containing attachments is displayed in the message list without the expected paperclip attachment icon, and, more important, where the “Remove Attachments” command is disabled when the sent message is selected, which means that it is impossible to remove the attachment from the message.

This is a problem that really bothers me, because it means that large sent messages are accumulating in my Sent mailboxes and I cannot file them away, and the size of my entire Mail folder is ballooning. In less than three months, I have accumulated nearly 400 sent messages with a total file size of over 600 MB. It is simply ridiculous.

Apple still hasn’t done anything about this bug. I am not the only one experiencing it. I have received e-mail from other people complaining about the same problem, and there is a discussion thread on the Apple Support Communities web site.

Yesterday, I just got tired of waiting and decided to try and do something about it. Here is what I did.

First, I sorted my sent messages by attachment, which amazingly still appears to work. Since Mail does not display the paperclip icon, it’s a bit hard to tell where the list of messages with attachments actually starts, but one can use the message size as a guide.

Then I selected all the messages with attachments and moved them to a separate mailbox.

I selected that mailbox and chose the “Export Mailbox…” command in the contextual menu. This enabled me to save the entire mailbox as a .mbox file on my hard drive.

I then imported the .mbox file back into Mail, using the “Import Mailboxes…” command. And sure enough, once the messages were imported, they showed up in a list with their paperclip icon fully visible, and the “Remove Attachments” command was working, so I was able to remove the attachments from my sent messages.

I then deleted the original sent messages with their unremovable attachments from my Sent mailbox, and moved the stripped sent messages from the Import mailbox back into the Sent mailbox. Et voilà! My sent messages are now attachment-free, and instead of the attachments they include the proper line between square brackets indicating the names of the files that were originally attached.

Phew. Obviously the export/import round-trip using the .mbox file format does something to the message files that restores normal behaviour. It confirms my long-standing suspicion, which is that something is broken in the way Lion’s Mail encodes the sent messages. (When you upgrade to Lion from Snow Leopard, if you have sent messages with attachments in your Sent mailbox that were composed using Snow Leopard’s Mail, they behave properly, even in Lion’s
Mail. It’s only sent messages created by Lion’s Mail that pose a problem.)

I am not sure whether the round-trip actually removes useful information from the messages, but there is nothing that I can see missing. They still have the correct information in the headers (sender, recipients, etc.) and Lion’s Mail still organizes them by conversation properly, with the messages that they were originally connected to. The only glitch I have noticed is that, when a message includes both a plain text and a rich text version, the line between brackets with the name of the removed attachment only appears in the rich text alternative and not in the plain text alternative.

Obviously if you have rules that apply various colours to your messages, like I do, you’ll have to reapply the rules to the sent messages to restore their colours (via the “Message” menu). But after that, everything will be in order.

It’s obviously not a fix for the bug, but at least it enables you to periodically remove the attachments from your sent messages, which helps keep your overall Mail folder size reasonable.

Now if anyone has any tips about the steps required to provide a 100%-reproducible scenario to Apple via a bug report, I am all ears. Even though I can reproduce the problem in two different user environments on my machine, including one with zero customizations, it is apparently still not good enough…

It has always been, and still is, impossible to undo the command. Given that it is quite a destructive one, this makes very little sense, especially since there is no warning about it not being undoable.

And because the command was (still is?) essentially a hack, which consists of deleting the existing message and creating a new one without the attachment, for years the use of the command had the unfortunate consequence of deselecting the message that you were applying it to. Then Apple “fixed” this problem by causing the use of the “Remove Attachments” command to… select the next message in the list.

Then finally in Lion Apple fixed this problem by making sure that the message that you remove attachments from remains selected, which should have always been the case. That, folks, means that we’ve waited a full eight years for Apple to fix this particular problem.

Unfortunately, that is not the end of the story when it comes to the “Remove Attachments” command in Lion’s Mail, quite the contrary. Apple has actually managed to introduce new quirks and bugs.

The big one is that there is a very serious problem with sent messages containing attachments. As far as I can tell, it is simply impossible, in Lion’s Mail, to remove attachments from sent messages. Even when a sent message contains an attachment, Mail fails to include the paperclip icon next to the recipient’s name in the message list, and when you select such a message, the “Remove Attachments” command in the “Message” menu is disabled, which means that you cannot use it.

I did some additional testing before submitting this as a bug report to Apple and can confirm that, at least on my machine, the bug affects both POP and IMAP accounts. Even if you move the sent message containing an attachment from the Sent mailbox to another mailbox, Mail still refuses to show the paperclip icon or let you remove the attachment. In fact, even if you export the message from your own Mail environment and open it in another user’s Mail environment, the problem persists. So it appears that there is something about the way attachments are encoded by Lion’s Mail in sent messages that is wrong. Indeed, when I upgraded to Lion, I still had quite a few older sent messages in my Sent mailbox that had been created using a previous version of Mail, and these sent messages didn’t pose any problem, even in Lion’s Mail. The paperclip icon was there, and I was able to remove the attachments. The problem only affects messages composed and sent by Lion’s Mail.

It also affects the ability to send such messages again. If you select a sent message containing an attachment in the Sent mailbox and choose “Send Again” in the “Message” menu, Mail fails to include the attachment in the new copy of the message that it creates for you to send it.

In this discussion thread on Apple Support Communities, some users report being able to restore the functionality by moving the affected messages to other mailboxes or by rebuilding mailboxes, but neither fix works for me and I am not the only one who simply cannot get anything to work.

(As several contributors report, you can manually remove the attachment by opening the corresponding .emlx file in TextEdit and removing the section containing the encoded file, but it’s a royal pain, and it removes all traces of the attachment, without leaving any indication of what the file name of the attached file was.)

Then there is the very confusing situation caused by using the “Organize by Conversation” option in Lion’s Mail. When you select a conversation containing several messages, some of which contain attachments, the selected conversation heading (which looks just like any other message in the message list, except that it has a message count of more than 1) has a paperclip icon, but the “Remove Attachments” command is, as far as I can tell, disabled unless the last received message in the conversation contains an attachment — and then, if you can use the “Remove Attachments” command, it removes the attachment… from the older message in the conversation that contains one. It makes no sense whatsoever.

(There is a general fuzziness about which message is “selected” when you select a conversation, which deserves an entirely separate article.)

Why, oh why is removing attachments such a pain in Mac OS X’s Mail? I, for one, want to try and keep the size of my mailbox archive manageable and have no need to accumulate hundreds of old attachments within it. If I want to keep an attachment, I extract it from the corresponding message by saving it in a separate location on my hard drive, and then I remove it from the message in Mail. And of course, I have absolutely no need to keep copies of the attachments that I send with Mail in Mail, since I already have copies of them on my hard drive (which is how I was able to attach them in the first place, duh).

Right now, because of the major new bug with sent messages in Lion’s Mail, I have a a Sent mailbox that is becoming bigger and bigger by the day. (It’s already nearly 200 MB as we speak.) I sure hope that Apple fixes this particular bug soon, so that I can remove all these attachments and archive the sent messages without worrying about the amount of hard drive space that they are wasting.

But most important, we need Apple’s engineers to start taking the “Remove Attachments” feature seriously and make it an integral part of the Mail user interface, and not treat it as some neglected, buggy command that only a limited number of “advanced” users care about. Sadly, given the general dumbing-down trend that is characteristic of today’s computing technology, I am not sure there is any hope of this happening. Apple seems to think that most people do not archive their messages at all — or, more cynically, that if people’s mailbox archives grow to unseemly sizes faster, they’ll be encouraged to purchase new hardware faster.

As reported earlier, I installed Lion on my main machine last month, and since then I have of course encountered a number of bugs that I have been reporting to Apple through the appropriate channels.

But any major system upgrade can also cause you to encounter problems that you have never encountered before — and mislead you into thinking that they are new problems — simply because it causes you to change some of your behaviours.

Last week, for example, I went to the Trash mailbox in Mac OS X’s Mail for the first time since upgrading to Lion. (I only go there when I think I have mistakenly trashed a message that I wanted to keep.) And I noticed that it was… completely empty, even though I had just trashed a message! I tried again, and sure enough, the other message I trashed also disappeared right away altogether.

Uh oh, I thought. Is this another bug in Lion? I then went to my preferences to check the account settings for my various e-mail accounts and make sure that Lion had not changed them. They were still all set to automatically erase deleted messages either “never” or “after one month.”

I then tried to rebuild the trash mailboxes for the various accounts, to no avail. My deleted messages were most definitely gone. I went to my Mail folder in my home library in the Finder to see if they were there without actually showing up in Mail. The Mail folder has a new file/folder structure in Lion that makes it very painful to find individual e-mail files, but I was able to ascertain that my trashes really did not contain anything.

Figuring it might be some kind of new Mail bug in Lion, I tried the trick that consists of trashing the Envelope Index file to force Mail to reimport all messages (effectively rebuilding the index). Mail now has three Envelope Index files (in a subfolder called “MailData”), so I trashed all three and relaunched Mail. Sure enough, it prompted me to reimport all my messages, and I let it do that, which took a good 15 min.

After this, however, my Trash was still empty, which was not particularly surprising. But I noticed that new messages that I was trashing now were not disappearing right away, so I figured that trashing the Envelope Index files had fixed the problem.

Then a few days later I checked my Trash again, and it was empty again!

I then went to post a note on the AppleSeed discussion forum about this, in order to find out whether other testers had experienced the same problem. (I didn’t find anything on the main discussion forums or elsewhere.) Several people responded, indicating that they were unable to reproduce the problem and making various suggestions.

One of the suggestions was to check that I wasn’t accidentally requesting Mail to erase deleted messages. I first thought it was a silly suggestion, but then I saw that the poster mentioned not only the menu item for this (which I would never trigger by accident), but also the corresponding keyboard shortcut:

The shortcut is command-shift-Delete. “Bloody hell,” I thought. Could it be that I have been hitting this shortcut by accident? If so, why?

Then I thought about it, and figured the following. In Lion, Mail now has this “conversation” feature that automatically shows discussion threads consisting of the several messages, in both your Inbox and other boxes, that are part of the same back-and-forth e-mail exchange. It’s a pretty nifty feature, and a very convenient one. (It’s much better than the “Organize by Thread” feature of previous versions.)

But there is something about this new feature that maybe makes me subconsciously feel like I have to do more than a simple Delete keystroke when I want to delete a message or a group of messages. And since I am already used to the command-shift-option-Delete shortcut that I use all the time in iTunes to not only delete tracks from the current playlist, but also actually remove them from the library altogether, I think that maybe, since upgrading to Lion, I have unconsciously been using the command-shift-option-Delete shortcut instead of a simple Delete keystroke to delete some messages, especially when I am looking at a conversation.

Now, of course, command-shift-option-Delete is not the exact shortcut for “Erase Deleted Messages › In All Mailboxes” in Mail, but it includes that shortcut (command-shift-Delete shortcut), and that is enough for Mail to treat it as the same.

And sure enough, since this realization, I have been careful not to use the shortcut anymore, and I haven’t experienced any problem with messages disappearing from my trashes.

But is that the whole story? Not quite.

First of all, the shortcut is not new in Lion. The “Erase Deleted Messages › In All Mailboxes” command already had the same shortcut in Snow Leopard.

Then it turns out that there is a difference between command-shift-option-Delete and command-shift-Delete. The difference is that, if you use command-shift-Delete (or manually select the “Erase Deleted Messages › In All Mailboxes” menu command), you get the following confirmation dialog:

If you use command-shift-option-Delete, on the other hand (i.e. the shortcut plus the Option modifier key), there is no confirmation dialog. This is consistent with other similar shortcuts in other applications (such as the shortcut for emptying the trash in the Finder). You can also see the ellipsis at the end of the menu command disappear when you hold the Option down, which indicates that there won’t be a dialog box when you execute the command.

Here again, the behaviour is not new in Lion. The Option key has the same effect in Snow Leopard.

The fact that this is nothing new would appear to suggest that there is indeed something about Lion’s Mail that causes me, subconsciously, to want to use command-shift-option-Delete more than I used to. Again, I suspect that it has to do with the conversation feature, but that’s only speculation about my subconscious here.

I must also point out that I have a very long personal history of using command-shift-option- type shortcuts for various commands in various applications. There’s just something about that particular combination of modifier keys that feels natural to me on my keyboard, and so I end up using this type of shortcut quite a bit. (Ironically, I also believe I like this type of shortcut because it’s easy to memorize, yet difficult to trigger by accident.)

Based on what’s happening to me now in Lion, I cannot afford to be taking any chances about this issue (and risk losing messages that I don’t want to lose). I have now added a macro in Keyboard Maestro that intercepts the command-shift-option-Delete shortcut, and triggers the menu command itself, thereby forcing Mail to display the confirmation dialog.

(Isn’t it wonderful that a tool such as Keyboard Maestro enables you to fix or improve other software without resorting to hacks or other undesirable methods?)

If you are ever tempted to use more than just Delete to delete a message in Mail, I suggest that you look into this and take precautions to avoid accidentally (and irretrievably) emptying your trash in Lion’s Mail, which can happen without giving you a warning about doing something drastic that cannot be undone.

One of the side benefits of this new feature is that it also supports keyboard shortcuts for moving your messages to these favorite mailboxes. The mailboxes are numbered in the order they appear in the bar, and you can use the command-control-n shortcut, where n is the number of the mailbox, to move the currently selected messages to that mailbox.

Me, I didn’t wait for Apple to come up with this feature to find solutions of my own. As Betalogue readers know, I am a MsgFiler convert, and I use it for most of my message moving operations.

But for really frequently used mailboxes, even MsgFiler requires too many keystrokes for my taste. So until recently, I was also still using Mail Act-On, which is a Mail plug-in that lets you define “rules“ with simple keyboard shortcuts to perform various actions, including moving messages to specific mailboxes. With Mail Act-On, I could have simple shortcuts like ctrl-U or ctrl-H to move messages to very specific, very frequently used mailboxes.

The problem with Mail Act-On is that it’s a plug-in, and Apple’s support for Mail plug-ins appears to be half-hearted at best. Typically, every new version of Mac OS X (even the incremental updates) requires updated plug-ins. Since I am part of the AppleSeed program for testing system updates, I encounter the issue all the time, almost with each new version of each update. There are ways to cheat and make plug-ins compatible when they don’t appear to be, but it’s painful to have to do it every time.

The truth is that my use of Mail Act-On is limited to a few key shortcuts for moving messages. And now with Mail 5.1, I don’t really need it anymore. Why? Because I can use Keyboard Maestro to create macros that use the same shortcuts that I used to have with Mail Act-On, and have these macros trigger the above-mentioned command-control-n shortcuts. So, while Mail’s shortcuts are limited by this number-based scheme, Keyboard Maestro actually lets me customize the shortcuts to my liking, and I don’t have to try and memorize these new number-based shortcuts instead of the ones I am used to.

I don’t have more than 10 high-frequency mailboxes, so I am OK with the limitations of the favorite mailboxes feature. I had been waiting for a feature like this for years. But in typical fashion, it took Apple way to long to actually implement it, and I ended up purchasing third-party software to implement similar schemes, which comes with its own drawbacks, namely the cost and also the fact that third-party software is not always fully supported and as integrated as built-in features.

Now, with MsgFiler and this new customized use of the favorite mailboxes bar with Keyboard Maestro, I can reduce the amount of third-party software that I use. It is still not as good as having full customization features built in and supported by Apple directly, but I cannot afford to wait for that long.

In more recent versions of Mail, the bug changed without getting fixed. Instead of just deselecting the message after removing its attachments, Mail would… select the next message in the list (except when a whole thread was selected).

Now, in Mail 5.0, “Remove Attachments” no longer deselects the message. Obviously Apple’s engineers have finally eliminated the weird trickery that they used previously to remove attachments.

Coincidentally, this morning I received a follow-up e-mail from Apple about another related bug that I had submitted to them in a bug report, after exploring it in a discussion on the AppleScript forum at Apple Discussions last year.

I uncovered the problem while attempting to write a script to work around the problem with Mail deselecting messages after removing their attachments. I obviously do not need such a script anymore, but it appears that Apple’s engineers have fixed the message selection issue in AppleScript at the same time, possibly as part of the same general bug fixing process.

The sample script that I had sent to Apple with my bug report was as follows:

tell application "Mail"
	activate
	set selectedMessages to selected messages of message viewer 1
	tell application "System Events" to tell process "Mail"
		key code 126
	end tell
	try
		set selected messages of message viewer 1 to selectedMessages
	on error
		get selectedMessages
	end try
	get selectedMessages
end tell

This script simply would not work reliably with a message selected in Mail. Sometimes it would work, sometimes I would get an error saying “selectedMessages variable not defined.” There was obviously something broken in “set selected messages” in Mail’s AppleScript support.

Now, when I try to run the script, it seems to be working fine every time.

Like I said, I no longer need to write a script for fixing the “Remove Attachments” bug, since they fixed it, but it still is a good thing that the message selection bug in Mail’s AppleScript support has been fixed as well.

Now, things are not quite perfect in Mail 5. While “Remove Attachments” works fine on a single selected message or a selection of individual messages, I cannot get it to work on a conversation, i.e. when I select the conversation heading itself.

Whenever I select a conversation heading, the “Remove Attachments” command becomes disabled. This appears to imply that selecting a conversation does not actually select the enclosed messages. And yet, when I try to move a conversation to a different mailbox after just selecting the conversation heading, Mail does correctly move the entire conversation, including all the enclosed messages.

So there is still some message selection inconsistency here. Visually speaking, if you click on the small control that displays the message count for the conversation, Mail expands the conversation to reveal all the individual messages it contains:

And after that, if you click on the conversation heading itself, you’ll see that Mail selects it without selecting the enclosed messages. And yet, as I said, even with such a selection, if you try to move it, the entire conversation gets moved, including the individual messages that do not appear to be selected:

I can shift-click to add the enclosed messages to the selection:

But doing this does not cause the “Remove Attachments” command to become enabled again, so it won’t work to remove attachments from all the messages in a conversation either.

The only thing that will work is to select the enclosed messages without selecting the conversation heading itself:

Then, and only then, if the selection includes messages with attachments, the “Remove Attachments” command will become enabled and usable again.

Adding a level of abstraction such as this “conversation” concept obviously poses a number of challenges and, on the whole, I think that Apple did a decent job in Mail 5.0. (I am still familiarizing myself with it.) But I still wish that they were a big more careful about remaining consistent throughout the Mail UI. Either clicking on a conversation heading selects the enclosed messages, or it does not. If it does not, why does moving the conversation heading also move the enclosed messages? If it does, why is the “Remove Attachments” command disabled?

[UPDATE: I am actually mistaken about moving messages. If you select a conversation heading and move it, only the last (most recent) message in the conversation is moved. This makes things even more confusing, because the last message is somehow "selected" without being selected.]

The fundamental problem is that Apple’s engineers choose keyboard shortcuts based in part on the positions of the keys involved on the U.S. keyboard layout, and apparently they don’t always bother to make sure that these shortcuts make sense or are at least usable in other keyboard layouts.

And now in Lion we have a new one to add to the list. When an e-mail message contains both plain text and rich text versions of the message, you can use the command labelled “Next Alternative” to switch from one version to the next:

As you can see in this screen shot, the keyboard shortcut for this command is option-command-]. That is not new in Lion. What is new in Lion’s Mail 5.0 is this:

In previous versions of Mail, the shortcut for toggling the visibility of the “Activity” window was simply command-0. Now, in Lion’s Mail, it’s option-command-0.

And guess what? On the Canadian CSA keyboard layout, the shortcut for the “]” character itself is… option-0. I think you know where this is heading…

Yes, on the Canadian CSA keyboard, the option-command-] is not really possible, because the “]” character itself requires the option key — whereas of course, on the U.S. keyboard, the closing square bracket has its own stand-alone key:

On a Canadian CSA keyboard layout, option-command-0 and option-command-] are the exact same shortcut. And of course, in Mac OS X, when two menu items have the same shortcut, the one that takes precedence is the one farther to the right in the menu bar — in this case the “Activity” command, which is in the “Window” menu.

And so, on the Canadian CSA keyboard layout, the default shortcut for “Next Alternative” no longer works.

It is possible that you might be able to fix this situation by tinkering with Mac OS X’s built-in keyboard shortcuts feature in System Preferences. Personally, however, I lost patience with Apple’s on-going treatment of keyboard shortcuts as second-class citizens a long time ago and now, when I encounter such a situation, I head directly to Keyboard Maestro and configure it to intercept the shortcut in question and handle the triggering of the actual menu command itself:

It works perfectly well, and with Keyboard Maestro I know that my customizations are in safe hands.

In spite of my initial reluctance (due in part that I had already shelled out some cash for Mail Act-On and didn’t want to add too much to the complexity of my e-mail setup), I ended up purchasing MsgFiler and quickly became a fan of the product.

Then Apple announced the Mac App Store, with all its rules and limitations, and I started to worry about some of the vital third-party tools that I use and what they might become in a Mac software industry dominated by the Mac App Store and its staunch rejection of any software that might not be 100% above board in terms of the way it interacts with the underlying operating system.

I read Jon Gotow’s post about the disappearance of the “Apple Downloads” section of the Apple web site and its potential impact on Jon’s products. I am a long-time user of Default Folder and I simply cannot imagine life without it.

Jon says that Default Folder X and his other products aren’t going away, but it’s still a concern when the provider of the underlying OS has such a restrictive vision of what its developers and users should and should not be able to do with their computer. Who is Apple to decide that my use of a tool such as Default Folder X is “bad” and cannot be condoned? I am more than willing to temporarily disable Default Folder X whenever necessary to verify that a bug in Mac OS X is not caused by its presence, but I am definitely not willing to stop using Default Folder X simply because Apple decides that it’s not consistent with its software development philosophy. We are not talking about a third-party hack that unnecessary wastes CPU cycles to display trendy useless 3D junk on the screen here. We are talking about a third-party utility that is really useful, no matter what Apple thinks or says.

Anyway, back to MsgFiler… The original MsgFiler that I purchased last year and became an avid fan of was a Mail “bundle,” which is some kind of extension that is sort of supported by Apple for Mac OS X’s Mail. (Such extensions go in a folder called “Bundles” inside your home library’s “Mail” folder.) I say sort of supported, because whenever I submit a Mail bug report to Apple with a crash log, the first thing that the engineers ask in the reply, in a very terse tone, is that I disable my Mail bundles and try to reproduce the problem without them. (I usually am, but they won’t take my bug report seriously until I verify this myself.)

So, when Adam Tow, developer of MsgFiler, sent an e-mail to everyone back in February 2011 announcing that he would discontinue his current product and start selling a new version of MsgFiler exclusively through the Mac App Store, I became a bit worried. Could he really sell a Mail extension/bundle through the Mac App Store? Would it work as well as the current version did?

When MsgFiler 3.0 came out on the Mac App Store, I went ahead and purchased it, but the first impression was not good. MsgFiler had indeed become a stand-alone application and was no longer a mail extension. There were some serious bugs, and there seemed to be a loss of functionality, especially in the ability to undo a message move done by MsgFiler with a simple command-Z within Mail.

However, much to Adam Tow’s credit, I must say that, within a week of the initial release, all of the problems were solved. Adam fixed the bugs that I had encountered, and explained what I needed to do to regain the ability to undo. It was stellar service and I was quite impressed.

While the MsgFiler application is now sold exclusively through the Mac App Store, Adam still provides an free download of something called the MsgFiler Engine on his own web site, which helps alleviate some of the limitations associated with the fact that MsgFiler is now a stand-alone application. The MsgFiler Engine is effectively a Mail extension that replaces the old MsgFiler bundle and duplicates some of its benefits for the new application. (It is apparently particularly useful for people with IMAP performance issues, which is not something that affects me much, since I still mostly use POP accounts.)

It should be noted that the existing MsgFiler 2.x extension/bundle still works with the latest version of Mac OS X’s Mail, and that you can even keep it as an extension in Mail alongside the new MsgFiler application, as long as you assign two different shortcuts to the two utilities. (I have shift-command-Return for the MsgFiler 2.x bundle and control-shift-command-Return for the MsgFiler 3 application.) But in truth I now find myself using the application exclusively, and I am comfortable with it and no longer worried about MsgFiler being negatively affected by the transition to the Mac App Store.

The only drawback I see in the MsgFiler application is the time it takes to load the full list of mailboxes the first time you launch it. I have a lot of mailboxes, and the process can take a while. But now whenever I need to create a new mailbox, I do it within MsgFiler itself, so that it automatically updates its own list of mailboxes and does not have to rebuild it from the list of mailboxes in Mail. This way, I no longer experience any delays with MsgFiler having to reload the list of mailboxes from Mail.

All in all, I have to say that, in spite of the initial bumps, the transition to the Mac App Store, at least for MsgFiler, was a success, and that I will definitely continue to use and support the product.

Of course, what happened with MsgFiler tells us nothing about what will happen with a third-party tool such as Default Folder X, which is another kettle of fish, since, even though I am not a developer, it is quite obvious to me that there is simply no way that Default Folder X could ever become a stand-alone application that complies with all the restrictions imposed by Apple on Mac App Store applications.

Then again, given the way things are evolving in the computing world at present, with the convergence of mobile and desktop computing, it is really hard to tell where we will be ten years down the road in terms of processes such as creating/saving and managing files and folders. So who knows what Default Folder itself will become further down the road? For now, though, it’s still an essential part of the Mac OS X computing experience for me and losing it would be a significant step back in my productivity.

Ultimately, my productivity was not affected by the MsgFiler transition from extension/bundle to stand-alone application imposed by the Mac App Store, but in the long run, it still remains to be seen how this transition might or might not affect some essential third-party tools that so many advanced Mac users cannot do without.

Now that I am on a proper broadband connection, I figure that I can use at least some of my e-mail accounts as server-based IMAP accounts rather than old-fashioned POP accounts. In particular, I have now configured my MobileMe e-mail account to work with the default account type suggested by Mail, i.e. “MobileMe IMAP.”

This means that I am now able to test and indeed reproduce some of the issues that have been plaguing IMAP account users in Mac OS X’s Mail for years.

Here is one flaw in particular that I was able to fairly easily reproduce several times in a row yesterday and is really unacceptable. If I selected a certain message that I had in the Inbox for my MobileMe account and pressed Delete to delete it, and then immediately pressed command-Q to quit Mail, I would get this:

To make things worse, Mail was now in some kind of altered state where most menu items were greyed out, including the “Quit” command in the “Mail” menu, which meant that I could no longer either bring Mail back to its normal state or quit it. My only option was to force-quit it!

Mind you, this does not happen all the time, and today when I try to reproduce the same problem with the same message, I can no longer do it. (Mail quits as expected, and then resyncs the various MobileMe mailboxes properly once it’s relaunched.)

But I certainly did make the above dialog up, and I definitely was able to reproduce the problem several times in a row yesterday afternoon.

While I was reproducing the problem repeatedly, I was also able to use Snapz Pro X to capture the contents of the “Mail Activity” window, which gives you a more detailed account of the various things that Mail is in the process of doing:

Apparently, yesterday afternoon, the mere fact that these two processes were in progress at the time I pressed command-Q to quit Mail was enough to trigger the alert and to put Mail in that altered state that I was unable to get out of.

And I have seen this altered state before. It’s not the first time I encounter it.

Now, granted, my broadband connection is not superfast, and probably not as fast as the network connections with which most Apple engineers do their testing most of the time. But I don’t think that this is a valid excuse. Mail should be able to work properly under a variety of circumstances, including less-than-optimal network throughput. And it should definitely never become stuck in a state where it can neither be used nor be quit without having to resort to a force-quit.

In its “Preferences” dialog, Mail has a feature called “Rules” that allows you to create rules to automatically perform actions on incoming messages that match certain criteria.

One of the actions you can perform on messages is to change the colour of the message viewer:

As the screen shot above shows, you can change the colour of either the text or the background for the entire line for the message in the message viewer. If you change the text colour, you get something like this:

And if you change the background colour, you get something like this:

The problem in Mail is that, if you select a message who text colour has been changed by a rule and then reply to it, as soon as the reply gets sent, the text colour changes back to black.

This problem first appeared back in 2004. I reported it to Apple, and it ended up getting fixed at some point in 2005.

Unfortunately, the bug resurfaced back in 2007, and it’s been with us ever since.

I have submitted several bug reports to Apple, to no avail.

The problem might be partially my fault, in that I didn’t always provide the full details of the situation. In particular, this bug has one particularity: it only affects the text colour, not the background colour.

In other words, if you have a rule that automatically changes the background colour of certain messages, and if you select one such message and reply to it, the background colour will not be lost.

Since one of the default rules that is included by default in Mail when you first launch it in Mac OS X is a rule labelled “Apple Mail” that automatically applies a pale green background colour to messages coming from the apple.com domain name, I suspect that this is as far as Apple’s engineers go when it comes to checking and making sure that the colouring actions in Mail rules work properly. So they do not seem to have noticed the bug described above, which only occurs when you reply to messages whose text colour has been changed by a rule. Or at least they don’t feel that it’s a priority to fix it (to say the least!).

You can restore the message’s text colour after the bug has changed it back to black by re-selecting the message and re-applying the rules (command-option-L), but it’s a tedious process.

For years, I have used various text colours to distinguish between categories of e-mail and make high-priority e-mails (from work contacts) stand out. And so for years I have had to deal with this bug. But last week I finally got tired of having to manually re-apply my text colours, and so I changed my main rule (the one that makes high-priority work e-mails stand out in a specific colour) so that it applies a background colour instead of a text colour.

And now I no longer lose the colour for these important messages when I reply to them.

It’s a small change, but it makes a big difference in my daily work life.

The lesson here appears to be that, when a piece of software that you use has a bug that the developer, for some reason, has failed to fix for several years, there is no point in maintaining a situation where you have to deal with the bug on a daily basis. It’s much more sensible to do your best to work around the problem and make it disappear… into the background.

Unfortunately, there are also many bugs that you cannot work around and so you still have to live with them on a daily basis. But in this particular case, there is a workaround, which simply involves using background colouring rather than text colouring. It certainly makes your message list look “busier,” because a big blob of background colour is significantly more noticeable than a change in text colour, but since the whole point for me in this case is to make the message stand out, I guess I can live with the “busier” look.

Still, I should point out that I submitted yet another bug report about this about a month ago, and got another e-mail back from Apple asking me to provide the bug report numbers for the older bug reports about the same bug. It gave me the opportunity to clarify once and for all that the bug was not about colouring rules in general but only colouring rules that change the text colour. Maybe now that this is absolutely clear, the bug will finally get fixed. But after all these years, I am not holding my breath, and I’d rather live with a change to background colouring in my main rule, so that I no longer have to remember to re-apply the rule to important messages after I reply to them and Mail strips their custom text colour.

I am working on a Word document authored by someone else. (I have no idea what version of Word they used. It’s apparently too much to ask that Word include that information in the document itself, in its “properties.”)

Here’s what a particular section of the document looks like in Word XP under Windows XP:

Here’s what the same section looks like in Pages ’09 after importing:

And finally, here’s what the same section looks like in Word 2011 for Mac OS X:

Ah, what would we do if we didn’t have the MacBU to foul things up, uh?

(Try as I might, I cannot get Word 2011 to display the picture properly. Resizing just resizes the whole thing. I cannot get rid of the extra block of green that pushes all the text below too far down.)

I don’t give a flying duck what the exact format of the picture is. When I copy it from Pages ’09 and open it as a new document in Preview and then scale it up, the text still looks fairly good, albeit a bit fuzzy:

So it could be some kind of vector picture, although I don’t understand why it’s fuzzy. Whatever the picture format is, the MacBU would probably use the excuse that it’s not a low-resolution bitmap from 1995 to justify its failure to render it properly.

Of course, if I copy the damaged picture from Word 2011 and do the same thing in Preview, the result is not as good, because Word 2011 has its own crappy way of dealing with the Clipboard:

Also, half of the time, when I copy some text in this document in Word 2011 and try to do “Paste and Match Formatting” in another section of the same document, the application… freezes, and I have to force-quit it.

And this is not the first Word document that this has been happening with.

Crap, crap, and more crap from the MacBU. Some things never change.

When I compose a message in Mac OS X’s Mail and then go to the toolbar to click on the “Send” button to send it, I regularly manage to hit a “dead” spot when clicking does nothing, even though my mouse is clearly—as far as I am concerned—somewhere over the button.

Upon further investigation, it looks like the area I am hitting is this one:

I don’t know about you, but to me this is an area that should be considered part of the clickable area for the “Send” button. Yet it is not. Clicking on this does nothing, except if you click-and-hold and then drag the mouse pointer, in which case it moves the whole message window, because effectively what you are clicking on is the background of the window’s title/toolbar, which acts as the general target area for clicking-and-dragging to move the window around.

To me, this particular area should clearly be part of the button, because it is well within the width defined by the button icon, and it is between the button icon and the button text label.

Yet for some reason Apple has designed things so that this particular area between the button icon and the button text label is not part of the clickable area. In order to click on the “Send” button, you must click either on the icon itself or on the text label itself. And if the text label is not as wide as the button icon, then there is a “dead” area where clicking does nothing.

Things are not helped by the way the button visually responds to hovering over it with the mouse pointer. If you hover over the button icon, the button switches to a darker shade of grey for its background:

But if you hover over the button text label, there is no visual indication that you are hovering over a clickable area:

You are just supposed to know that clicking on the text label also works. But where does the clickable area defined by the text label start and stop exactly? There is no way to tell, since there is no change in colour to indicate that it is ready to respond to a click.

This is all the more absurd since when you do click on the text label, the button icon does changes to the even darker shade of grey that indicates that you are currently clicking on the button:

If it does change to that darker shade of grey for mouse-down, why does it not change to the medium shade of grey for mouse-over?

It just does not make sense. Two improvements are required here: the button icon should change to the medium-dark shade of grey when the mouse hovers over the text label too, and the clickable area for the text label should always be at least as wide as the button icon itself, even if the length of the text label is shorter than that width.

It can be a time-consuming process and the rewards are pretty scant. (We usually get a free copy of the new system once it’s officially been released, and the occasional t-shirt.) But it is sometimes gratifying to be able to give feedback and get a response from Apple engineers that indicates that they take your suggestions seriously.

For the most part, as far as I can tell, Apple expects AppleSeed testers to report on bugs. There is a form for suggesting enhancements (such as new features or improvements to existing ones), but they rarely elicit a response and when they do, it is often discouraging, taking the form of a canned “The software behaves as expected” reply.

Still, I cannot help but submit such enhancement suggestions from time to time, simply in the hopes that someone will lend an attentive ear, actually think about the issue for two minutes, and maybe add the request to a “to do” list.

Back in 2007, I submitted such an enhancement suggestion, noting that, when one right-clicks on a mailbox folder in Mail’s mailbox drawer, the contextual menu did not contain a “New Mailbox…” command. At the time, if you wanted to create a new mailbox inside an existing mailbox in Mail, you had to select the target mailbox, then travel down to the “+” menu at the bottom of the mailbox drawer and use the “New Mailbox…” command in that menu (or alternatively, the “New Mailbox…” command in the “Mailbox” menu in the menu bar).

My view was that the “New Mailbox…” command was a context-sensitive command, since it creates a new mailbox inside the currently selected mailbox. So it made sense to include the command in the contextual menu that you get when right-clicking on an existing mailbox—in addition to the other, existing ways of accessing that command.

Sadly, I quickly got the afore-mentioned canned reply:

After reviewing your submission engineering has determined that the behavior you reported is as expected/designed.

So I didn’t insist and just let it be. Even though I kept using the contextual menu on an existing mailbox and expecting the “New Mailbox…” command to be in there—I just couldn’t help it—obviously it was not a big issue and both Apple and I had bigger fish to fry.

Imagine my slight surprise then the other day when I went to create a new mailbox by right-clicking on an existing mailbox in my mailbox drawer and… found the “New Mailbox…” command there at the very top of the menu:

In fact, it was so logical to me that I didn’t realize right away that this command didn’t use to be there. I took my brain a few moments to reactivate a few dormant synapses, but eventually something in the back of my head whispered: “Hey, this command didn’t use to be there! It was something I sent an enhancement request about to AppleSeed several years ago and got a canned reply to!”

And sure enough, when I checked my e-mail archives today, I found the old e-mail exchange, and the reference number for my enhancement request that went nowhere at the time.

Even though I got the canned reply when I submitted my own enhancement request, it does look like eventually, somehow, the message got through, and someone at Apple finally agreed with my suggestion and made the improvement in Mail for Snow Leopard.

Does this mean that the command is there in the contextual menu because of my submission? I have no way of verifying this, of course, especially since I never received any further follow-up after the canned reply. (Sometimes I do get a follow-up e-mail, even years later, and it’s often absurdly out of date.) It is more likely that someone else submitted an enhancement request and was more persuasive than I was, or that someone internally at Apple realized without prompting one day that it did actually make sense to include the command in the contextual menu as well.

In any case, the bottom line is that the command is finally there, and that this is further evidence that either Apple does listen to the feedback that it gets from its users and testers or it has a fine team of engineers who keep looking for ways to improve their software, even in very minor ways such as the addition of this alternative way of accessing the “New Mailbox…” command.

That makes me hopeful about the future, even though I still find that the pace at which improvements and enhancements are made is often far too slow. At least it gives me a little bit more incentive to continue participating in the AppleSeed program and try and help further improve Apple’s products.

One is about the third-party MsgFiler plug-in for Mail. In my previous post on this topic, I wrote:

Unlike LaunchBar, as far as I can tell, MsgFiler does not have a smart abbreviation engine that “learns” your preferred destinations based on abbreviated versions of their names. It just matches what you type to the actual names of the mailbox folders.

If, like me, you have lots of subfolders that start with the same word, then you need to type not just that whole word but the beginning of the next one (or hit the cursor keys multiple times to select the right item in the list of matches). For example, I have mailbox folders called “Betalogue – Admin,” “Betalogue – Mail,” “Betalogue – Feedback,” etc. In order to select one specific mailbox in that group, I have to type “Betalogue -” and then the first few letters of the next word. That’s a lot of typing.

The same issue applies to family members. I have a mailbox for each family member and, of course, many of them have the same last name, which I usually type first so that mailboxes are sorted alphabetically. Here again, in order to narrow things down to a specific mailbox, I have to type the whole last name and then the first few letters of the first name. Again, that’s a lot of typing.

A couple of readers wrote to indicate that you don’t necessarily have to type out the first word in the name of a mailbox. For example, to get to “Betalogue – Admin,” if I have multiple mailboxes starting with “Betalogue,” I could type “Admin” instead.

The problem with this, of course, is that I also have multiple mailboxes with the word “Admin” in their name. Similarly, when it comes to people’s names, if the last name is common to multiple mailboxes, I could type the first name. But here again, I have multiple acquaintances with the same last name, and I also often have multiple acquaintances with the same first name.

A more useful note with a view to reducing typing is that you don’t have to type out words in full. For example, to select “Betalogue – Admin” in MsgFiler, I just need to type out “bet ad.”

This is good to know, except, of course, that, in this particular case, in my mailbox drawer, “Betalogue – Admin” is not just a mailbox itself, but also a folder containing multiple subfolders. So I still get multiple results when typing “bet ad,” although the “Betalogue – Admin” mailbox itself is the first result (i.e. the one selected by default) and the other mailbox subfolders enclosed within the “Betalogue – Admin” mailbox folder are listed afterwards and can be selected directly by typing portions of the words in their own name.

It all depends on the names used for one’s various mailboxes and mailbox folders, of course. I have a long-established system that I use and I have no desire to change it after all these years. It means that, in my case, MsgFiler might require more typing than it would for other people with other naming systems.

It can still be argued, however, that, even in my situation, MsgFiler is still more convenient and efficient than the default message filing options available in Mail. I will have to give it another try over a number of days and see if I can really get used to it and find it more efficient than Mail’s options and consider it worth the expense and the additional burden of having to manage yet another third-party plug-in. (I am not giving up Mail Act-On for the single keystroke shortcuts that I have defined for my most common mailbox destinations.)

Speaking of Mail Act-On, another reader wrote to point out that Mail Act-On has its own feature for filing messages in any mailbox, aside from its rule-based keyboard shortcuts that can be defined by the user and used for specific mailboxes.

Under “Menus” in the Mail Act-On preference pane, there is a shortcut for a command named “Move Messages.” The default shortcut is F3.

However, as I wrote in my reply to this reader, I have to report that, on my system, that command is unusable. On my system, the window that pops up for message filing is totally unresponsive, or responds to key strokes (or mouse actions) after a delay of many seconds. It is unacceptable.

It was already like this a couple of years back when I first tried the feature, and it is still like this on my 2009 Mac Pro.

The reason might be that I have a large number of mailboxes (nearly 2,000). The reader who wrote to me and who uses this feature all the time only has 40 mailboxes. He has tens of thousands of messages, but only a limited number of mailboxes, and mostly relies on Mail’s search feature to locate individual messages.

I obviously have a different approach. And it looks like Mail Act-On’s “Move Messages” command is useless when the number of mailboxes is large. (Other Mail Act-On features still work fine.)

In closing, I think it’s fair to say that, for people frustrated with Mail’s built-in options for moving messages around, there are third-party alternatives, but that these third-party alternatives are an extra expense and might not work for everyone. My wish is still for Apple to include more efficient built-in solutions, but until that happens, I will definitely give MsgFiler another try.

Unlike AppleScript scripts or Mail-Act On rules, MsgFiler can be used to move messages to any mailbox in your mailbox drawer. The idea is that you define an application-wide keyboard shortcut for the “Move with MsgFiler” command that gets added to the “Message” menu in Mail after you’ve installed the plug-in.

With this keyboard shortcut, you invoke a small window where you can start typing the name of the intended destination, i.e. of the mailbox folder to which you want to move the selected message(s). MsgFiler finds and lists all mailboxes matching your typing, much like a utility like LaunchBar, which I use all the time.

Once you have narrowed down the list in MsgFiler to your intended destination (either by typing more characters or by using the cursor keys to select the desired item in the list), you can just move the selection to the destination by pressing Return.

MsgFiler works as advertised and is reasonably priced. But I had tried it a while back and decided not to purchase it because, in my experience, it still required too many keystrokes to obtain the desired destination.

Unlike LaunchBar, as far as I can tell, MsgFiler does not have a smart abbreviation engine that “learns” your preferred destinations based on abbreviated versions of their names. It just matches what you type to the actual names of the mailbox folders.

If, like me, you have lots of subfolders that start with the same word, then you need to type not just that whole word but the beginning of the next one (or hit the cursor keys multiple times to select the right item in the list of matches). For example, I have mailbox folders called “Betalogue – Admin,” “Betalogue – Mail,” “Betalogue – Feedback,” etc. In order to select one specific mailbox in that group, I have to type “Betalogue -” and then the first few letters of the next word. That’s a lot of typing.

The same issue applies to family members. I have a mailbox for each family member and, of course, many of them have the same last name, which I usually type first so that mailboxes are sorted alphabetically. Here again, in order to narrow things down to a specific mailbox, I have to type the whole last name and then the first few letters of the first name. Again, that’s a lot of typing.

That said, I will definitely give MsgFiler another try and see if I can live with its limitations and still improve the overall experience of moving stuff around in Mail.

(I am also reluctant to spend additional money and of course increase the risk of incompatibilities and instability in Mail by adding yet another plug-in.)

Here’s the situation as I encounter it on a daily basis. By default, I keep all my main mailbox folders in the “ON MY MAC” section of my mailbox drawer collapsed (i.e. closed) so that I can see them all. The last one in the list, as illustrated in the picture below, is a folder called “Work”:

As you can see, when all my folders are collapsed, the last one is still visible above the bottom edge of my mailbox drawer. But of course, if I expand (open) any of these main folders, the list of enclosed folders extends far beyond the bottom edge of the drawer and I have to scroll down to see them all:

Now let’s go back to the initial situation, i.e. when all the folders are collapsed:

If I now drag a selection of messages from my message list to the “Work” folder and wait for a fraction of a second, the automatic spring-loading mechanism causes Mail to expand the folder to reveal its contents:

So far so good. But let’s say the enclosed folder to which I want to drag my selection is lower down in the list. In order to reach it, I will have to scroll down the list of enclosed folder. But I have my index finger on my primary mouse button, because I am dragging stuff. So I cannot use the scroll wheel for this.

The expected standard behaviour in such a case is that, when I drag my selection near the bottom edge of the drawer and wait for a fraction of a second, Mail will start scrolling down the list to reveal the rest of the enclosed folders.

But that’s where there is a problem. The “near the bottom edge of the drawer” area that I am supposed to target with my dragging is not clearly defined and, more important, it overlaps with the area where one of the enclosed subfolders appears (in this case, the folder called “Graphic Designers”).

So what’s going to happen when I try to drag my selection near the bottom edge of the drawer and wait for a fraction of a second? Instead of simply scrolling down the list, Mail will also activate… the automatic spring-loading mechanism for the “Graphic Designers” folder:

But that’s not what I want! I do not want to drag my selection to a sub-subfolder inside the “Graphic Designers” folder! I want to drag my selection to a subfolder after the “Graphic Designers” folder.

Unfortunately, because of the overlap between the area that triggers scrolling and the area that triggers spring-loading, I cannot have one without the other. And the end result is that I have to scroll down through the list of sub-subfolders first before I can reach the rest of the list of subfolders.

Fortunately, Mail doesn’t continue this silly behaviour ad infinitum. Otherwise, it would be a nightmare. It only confuses scrolling and spring-loading once, presumably because after that, since the drawer is scrolling down, I am not longer lingering on any given position long enough to trigger spring-loading, until I actually choose to stop the scrolling by lifting my selection back up a bit.

And once I’ve actually dropped what I was dragging in the desired location and released the mouse button, of course Mail collapses everything back up and I am back to normal.

Still, it’s quite frustrating that, almost every time I want to archive something somewhere inside my hierarchy of mailbox folders, I am forced to deal with this confusion between scrolling and spring-loading and scroll through more things than I should have to.

Given that this is a problem that only affects people with a long list of folders in their mailbox drawer, and not the majority of users who never archive their mail outside their inbox and let it balloon up to thousands of messages, I wonder whether Apple is even aware that there is a usability issue here and, if so, whether they can be bothered to think about a way to fix it.

Admittedly, it’s a small problem, and one that I have learned to live with. But it still grates that I always have to do more scrolling than should be necessary and deal with unwanted spring-loading which, as far as I can tell, cannot be turned off (and one wouldn’t want to turn it off anyway, since it is necessary; the only option would be to turn it off only in this particular area of the drawer).

(And yes, I know that I can avoid all this by using right-click to browse my mailbox folder hierarchy via the “Move To” contextual menu command, but that comes with its own set of problems, because the menu font is bigger, and hierarchical menus require greater mouse movements with a greater risk of overshooting and having to start all over again.)

I have a few AppleScript scripts and keyboard-activated Mail Act-On rules for moving stuff to my most frequently used destinations, which helps alleviate the problem, but I cannot have a rule or script for every possible destination, so I still have to deal with this problem on a daily basis. And that, in my book, makes it more than a “minor” annoyance.