Re: [MlMt] insertFormatString... ${} expansions listed somewhere?
> On Sep 19, 2014, at 4:20 PM, Kai Großjohann wrote: > > And don't we all love those responses that say "Please see my replies below > in orange." Don't get me started. OTOH, a few times I've tried to do inline replies, and the had to go to someone's desk to explain which parts were mine. I assumed user error until I saw how badly Outlook had slaughtered them. I no longer blame the users. ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] insertFormatString... ${} expansions listed somewhere?
On 19 Sep 2014, at 11:21, Benny Kjær Nielsen wrote: On 18 Sep 2014, at 21:48, Kai Großjohann wrote: Actually, I find that the Outlook threading is better than I had feared. It actually works pretty well for a "linear" thread like this one (the one I'm responding to): I think I should add here that I was talking about the Outlook threading more than the message content. I found it pretty cool that Outlook collapsed sequences of replies into one message, and only displayed extra messages on every "fork". About the content, read on... For the record, for me top/bottom posting is not just about the ordering. Top posting is a “lazy” reply style in the sense that it encourages adding a comment to the top of the email leaving it to the recipient to figure out what is commented. Yeah. I take pains to reiterate the points, leading to things like "on item 3". It's not as friendly as just quoting the relevant bit of the email, as I'm doing here. And don't we all love those responses that say "Please see my replies below in orange." Oh well. When in Rome, it seems I try to do as the Romans do... Kai ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Sharing my current key bindings
And of course I no sooner send that out than I find a bug. The subject
selection rules ought to use subject.body to ignore Re and Fwd
```
"s" = ( "selectWithFilter:", "subject.body = '${subject.body}'",
"moveToMailbox:", "trash" );
"s" = ( "selectWithFilter:", "subject.body = '${subject.body}'" );
```___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate
[MlMt] Sharing my current key bindings
I have a bunch of key bindings for mass selection and deletion of mail
messages. The deletion ones can be rather dangerous, so sometimes I just
use the selection ones and then hit delete (or file, or whatever is
appropriate).
(I also have an action that sends me a Growl notification of the
subjects and number of messages deleted if I delete more than a few,
that's useful for when I accidentally go overboard. I can upload that if
people are interested.)
The selection ones are particularly useful now that I'm using the
recently shared modification that adds an extra pane showing the
selected messages and (in my case) everything else with the same
subject. It makes it far easier to see what I just selected.
Of those, I probably use t, i, s, and f most often. 'dt' is great for
nuking a conversation you are done with. 'di' is good for deleting just
the conversation in your inbox, but not the items you've filed already
(e.g. you filed that useful post to MailMate, but you want to delete all
the replies). 'ds' is good for when threading isn't capturing
everything, or it's a bunch of automated messages with the same subject.
And 'df' is great for email notifications from online services (a dozen
messages from a store about new products).
In any case, here they are if anyone would like to try them. If you
haven't modified keybindings, they go in
`~/MailMate/Resources/KeyBindings/Kee.plist` and then you'd set your
Custom Key Bindings in preferences to 'Kee'.
Thanks to all the other MailMate users who made it possible to build
these. And of course, our favorite developer!
```json
{
// "r" = ( "replyAll:", "selectAll:", "decreaseQuoteLevel:",
"deselectAll:", "moveToBeginningOfDocument:", "insertNewline:",
"insertNewline:", "moveToBeginningOfDocument:" );
"r" = ( "addTag:", "HTMLReply", "replyAll:" );
"c" = "collapseThread:";
"e" = "expandThread:";
"j" = "nextMessage:";
"k" = "previousThread:";
"n" = "nextUnreadMessage:";
"p" = "previousUnreadMessage:";
"J" = ( "markAsNotJunk:", "removeTag:", "\\Seen",
"moveToMailbox:",'INBOX');
// delete commands
"d" = {
// Delete entire thread
"t" = ( "selectThread:", "deleteMessage:" );
// Delete the thread in the inbox, but leave filed items
alone
"i" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.path = 'INBOX'", "deleteMessage:" );
// Delete thread except mail that was mine (I sent)
"m" = ( "selectWithFilter:", "#thread-id = ${#thread-id}
and #source.path != 'Sent Messages' and #source.path != 'Sent Items'",
"deleteMessage:" );
// Delete thread except the stuff in inbox or sent (other)
"o" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.path != 'INBOX' and #source.path != 'Sent
Messages' and #source.path != 'Sent Items'", "deleteMessage:" );
// Delete the subject
"s" = ( "selectWithFilter:", "subject = '${subject}'",
"moveToMailbox:", "trash" );
// Delete by from address
"f" = ( "selectWithFilter:", "from.address =
'${from.address}'", "moveToMailbox:", "trash" );
// Delete any mail to this recipient
"r" = ( "selectWithFilter:", "#recipient.address =
'${#recipient.address}'", "moveToMailbox:", "trash" );
};
// select commands (good if you aren't sure what the delete in
thread action is going to do!)
"s" = {
// Select an entire thread
"t" = "selectThread:";
// Select just the items in the thread that are in my
inbox, leaving filed messages alone
"i" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.path = 'INBOX'" );
// Select thread except mail that was mine (I sent)
"m" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.path != 'Sent Messages' and #source.path !=
'Sent Items'" );
// Select thread except the stuff in inbox or sent (other)
"o" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.path != 'INBOX' and #source.path != 'Sent
Messages' and #source.path != 'Sent Items'" );
// Select the subject
"s" = ( "selectWithFilter:", "subject = '${subject}'"
);
// Select by from address
"f" = ( "selectWithFilter:", "from.address =
'${from.address}'" );
// Select any mail to this recipient (warning, I've had
this crash MailMate)
"r" = ( "selectWithFilter:", "#recipient.address =
'${#recipient.address}'" );
//"m" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and #source.mailto !=[x] \\$SENT.source.mailto" );
// "m" = ( "selectWithFilter:", "#thread-id =
${#thread-id} and from.address !=[x] \\$SENT.from.address" );
};
// FROM
Re: [MlMt] insertFormatString... ${} expansions listed somewhere?
On 18 Sep 2014, at 21:48, Kai Großjohann wrote: On 18 Sep 2014, at 17:54, Benny Kjær Nielsen wrote: On 18 Sep 2014, at 14:42, Jeremy Cowgar wrote: My company wants corporate email replied to in Outlook fashion :-(. That is simply depressing. I cannot imagine the reasoning behind such a strange requirement. I might be alone on this, but when I see this quoting style then “competent professional” are not the first words to cross my mind :-) Actually, I find that the Outlook threading is better than I had feared. It actually works pretty well for a "linear" thread like this one (the one I'm responding to): My comment was mainly triggered by the fact that a company would dictate a specific quoting style including making it look like it was generated by Outlook. In general, I dislike top-posting, but that was not the main issue here. I understand that mixing the different styles just gives weird results. So I understand why the company doesn't want different people to use different styles, because the mixture is worse than either style by itself. Agreed. And MailMate supports both top- and bottom-posting and I'm not going to dictate the use of one or the other -- also not on this list. For the record, for me top/bottom posting is not just about the ordering. Top posting is a “lazy” reply style in the sense that it encourages adding a comment to the top of the email leaving it to the recipient to figure out what is commented. This works in some cases and, ignoring the increasing quote levels, it can be fine for instant-messaging-like correspondence. Doing the same thing when bottom posting is of course even worse. Bottom-posting requires: * Cleaning up the replied email leaving out irrelevant parts (while not leaving out too much). * Answering/commenting each part of the email where it is relevant. This email is a good example of how I do this. Most often only one or two quote levels are needed, but in this email I had to use three levels before my first comment. When sending emails to multiple recipients (like on a mailing list) I find it is even more important to do this work. I write it once, but hundreds of people might read it. I spend a few more seconds on my email and each of them save those same seconds when reading it. To conclude and **close** this discussion before it begins: * “Bottom posting” is a really bad name and I should change it. * I'm not going to dictate a specific reply style on this mailing list. I'll just try to lead by example :-) * I do know that I and anyone thinking like me have lost this “battle” to Outlook and other main stream email clients many years ago. I'm in no way saying that I won't make MailMate more friendly to top-posting if anything is needed for that. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Rules didn't come along with update
Sorry Benny, it must have been just a fluke that an annoying Facebook message got through to my Inbox. Everything appears to be working and the reason I didn't see the rules is because I was looking in the wrong place. On 18 Sep 2014, at 7:48, Benny Kjær Nielsen wrote: On 18 Sep 2014, at 11:30, Bob Koss wrote: I updated MailMate yesterday and I noticed this morning that my previous rules were not applied to incoming mail. I went to look at my rules and there weren't any. That doesn't sound good. So far, I have no other reports about this, but I'm of course very interested in fixing any bugs related to this. Is there a way to recover without entering them all again? If you have a backup then you can copy this file to get your mailboxes back: ~/Library/Application Support/MailMate/Mailboxes.plist You *must* quit MailMate before copying this file. If you manage to do this and the rules disappear again then let me know. Are there plans to make rules available across computers I use. Sometimes I'll enter rules on my laptop and sometimes on my desktop and it would be nice if I didn't have to do this twice. Possibly sync using Dropbox? I only have some notes on thoughts about how this could work. Something like Dropbox could be used, but I think it might be better to simply use IMAP for this purpose (the user could be asked to select a special IMAP mailbox for MailMate settings). It's not as trivial as it sounds though :-) -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Notify on reply
On 19 Sep 2014, at 6:14, Jeremy Cowgar wrote: I wrote a post with instructions and screen shots showing how I accomplished this process. http://jeremy.cowgar.com/2014/09/18/mailmate-waiting-on-reply/ I would be very interested in any improvements, ideas or comments on the process. I'll be happy to edit/update the post with the community making things better. Great post!! Here are my comments: * Instead of `Thread-ID` you might want to use `“In-Reply-To” is in “Waiting on Reply” “Message-ID”`. Otherwise I think you get into trouble when waiting on a reply in a longer thread. * Maybe the mailbox should be named “Received Replies” since it contains the replies and not the original messages. * Note that given “Received Replies” you can easily add a counter in the Counters preferences pane and get a dock/menu-count or sound/notification when a reply arrives (sounds can also be done using rules and eventually notifications are also going to be available via rules). * A variant of this system is to add a condition to “Waiting for Reply” to only display messages older than X days. This would allow you to see messages for which you might need to remind the recipient that you are still waiting for a reply (please don't use that against me ;-) ). Alternative idea (which might not be much better): You can add a smart mailbox based on “Waiting for Reply” with the reversed condition: `“Message-ID” is in “Inbox” “In-Reply-To”`. Then add a rule to this mailbox with an archive action (no conditions). It'll always be empty, but it'll take care of moving waiting messages to your archive. But this breaks the “Received Replies” mailbox and I think the best way to fix that is to also add a “HasReply” tag to the archived message. Then base the other mailbox (Received Replies) on Inbox messages for which the parent has this tag. Hmm, that might require another smart mailbox -- well, I wrote this might not be much better :-) -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
