Mail 2.0: Commands that are not part of the ‘Undo’ loop

Posted by Pierre Igot in: Mail
May 18th, 2005 • 12:35 am

There’s little that’s more annoying than an application that lets you undo certain commands but not others.

Unfortunately, Mail has always suffered from this problem, and still does in Tiger.

More specifically, while you can undo the deletion of a message or the action of moving it to a different folder, you cannot undo the action of flagging a message as junk mail, at least not in “Automatic” mode.

When you are in “Automatic” mode for junk mail filtering in Mail, Mail automatically moves messages that it recognizes as junk mail to a special “Junk” mailbox. But if it fails to recognize a junk mail message as junk, obviously the message stays in your Inbox.

If you then select the message and tell Mail that it is junk by flagging it as junk (command-shift-J), Mail flags it as junk and automatically moves it to the “Junk” mailbox.

Which is fine. What is not fine, however, is that this cannot be undone. For some reason, this particular action is not part of the “Undo” loop. And I don’t see why. Deleting a message is. Flagging a message as junk is just another variation of the same operation. It doesn’t make sense that one is part of the “Undo” loop and the other isn’t.

I submitted this as a bug to Apple a long time ago, and they still haven’t fixed it.

Another thing that’s not part of the “Undo” loop is AppleScript scripts. Since Mail’s feature set for archiving messages in various mailbox folders is rather poor and doesn’t have something like a list of “favorite” mailbox folder destinations, I use AppleScript scripts to create commands to move messages to various specific mailbox folders that I use quite often.

This works fine — except that, here again, unlike regular message moving commands effected through the “Move To” menu or by dragging and dropping messages, the scripts are not part of the “Undo” loop, even though they consist of a single AppleScript command:

tell application "Mail"
        move the selection to mailbox "Family/IGOT Pierre"
end tell

This AppleScript command is clearly the equivalent of using the “Move To” menu or dragging and dropping messages. So it seems to me that it should be just as undoable as those.

Of course, providing the ability to undo AppleScript scripts is probably more of an architectural challenge. But it cannot be that hard if a software company such as Bare Bones Software can provide undoable AppleScript scripts in their applications.

When you think about it, this is precisely what AppleScript is supposed to be for. It’s supposed to enable the user to create custom commands that can be added to the default feature set of an application, so much so that you even forget that they are custom additions and are not part of the default feature set. (I am not talking about scripts involving multiple applications here, only about application-specific scripts.)

Apple’s decision to eliminate the application-specific Scripts menu in applications such as Mail and Safari is already a bad move in that respect. The fact that application-specific AppleScript scripts are not undoable is another drawback that effectively discourages users from using AppleScript to customize their applications.

It seems that Apple cannot make up its mind about what level of user-friendly customizability it wants to provide to its users.

3 Responses to “Mail 2.0: Commands that are not part of the ‘Undo’ loop”

  1. ssp says:

    Thanks for noting that… I don’t really want to write about Mail in detail as there’s so much wrong with it.

    Let me just add a few points here: Mail’s handling of Undo is even broken at a more basic level. Reply to a message, delete some of the commented text and write in between the comments. Then Undo. You’ll most likely end up with a mess (or has that become any better with X.4.1?).

    As for AppleScript and Undo… we’ve had quite a discussion about it on the Bibdesk Mailing list. It’s a difficult question what’s the ‘right’ thing to do there as one can argue that AppleScripts should be able to run in the background and not mess up the undo stack of the user who might be using the application at the same time. But then again, this is unlikely to happen and the user might just use AppleScript as part of his workflow and thus will want it to be undoable. Ideally AppleScript had an option to set in the script that applications can pick up. But it hasn’t at this stage.

    While I was in favour of the first solution at first as a matter of principle, the others convinced me that the solution where you can also undo things AppleScript did can be undone will be much more useful in the vast majority of cases. From the programming POV (in our case) it felt cleaner to make AppleScript undoable as you can then implement registering for undos at a very low level. Of course this may vary from application to application and depend on its history (and Mail’s seems to be a rather long one) but my impression is that having AppleScript actions undoable while at the an isn’t particularly difficult and thus remains largely a design decision (or unawareness of the problem).

  2. Pierre Igot says:

    Can you provide a reproducible scenario for the problem in Mail. I am having trouble reproducing your problem. (It undoes things properly.)

    Thanks for the additional information about AppleScript and Undo… To me, the simple fact that BBEdit does it so well (undoing script commands) is a clear indication that it is indeed quite feasible.

    Whether Apple actually cares enough to do something about it is another question.

  3. ssp says:

    I’ve just updated to X.4.1 and couldn’t reproduce the standard problem I saw last week. So perhaps they fixed it a bit.

    With the Undo thing it’s a question about knowing and caring. And as Mail is said to be quite an old application it may also be a bit tricky…

Leave a Reply

Comments are closed.