[MlMt] creating a smart mailbox that is choosy about attachments

2014-10-01 Thread Jason Davies

Dear list

I'm throwing myself on your mercy trying to sort out a smart mailbox. My 
colleagues have recently all taken to including a graphic, usually (but 
not always) called image001.png. It's beyond them to have it inline (as 
I do:)).


However these colleagues also send me a lot of attachments that I need 
to be able to find fairly quickly. I've been trying to create a smart 
mailbox that


- contains messages from a particular set of individuals (that bit I can 
do!),

- contain attachments that are NOT image001.png (or image002.png)

Sometimes these messages have the image AND a Word file (for instance, 
or pdf), sometimes they only have the Word file (etc).


I thought this would be fairly straightforward but seem not to be able 
to get the logic right. This is partly because X-attachment-type doesn't 
work as I expected (I thought I could write 'docx' in there but that 
returns nothing).


The smart mailboxes I've tried usually build like this:

Meet all conditions

1. Identify the people
2. Check there are attachments at all ('Attachment-Count' 'exists')

AT this point I have tried to think how to check what you could write as

If attachment count is 1
and attachment name is image001.png
then exclude from smart mailbox

But I can't translate that successfully into smart mailbox rules. 
Sometimes there are multiple word docs, for instance and there may be a 
signature graphic - or not.


I'm currently trying it by having multiple smart mailboxes which is the 
only way I see to exclude things but that is also not turning out as I 
hoped...;)___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


[MlMt] Messages not marked read on open

2014-10-01 Thread John Cooper
My preferences are set to mark messages read after 20 seconds. In every 
other mail program I've used, this setting applies only to the preview 
pane (Message View). However, when message view is off, and I 
double-click to open a message for viewing in a new window, the message 
is not marked read for 20 seconds. I can actually open a short email in 
a new window, read it, close it, and still have to mark it read 
manually. I'd prefer to have messages marked read as soon as I 
explicitly open them.

___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] Messages not marked read on open

2014-10-01 Thread Benny Kjær Nielsen

On 1 Oct 2014, at 14:19, John Cooper wrote:

My preferences are set to mark messages read after 20 seconds. In 
every other mail program I've used, this setting applies only to the 
preview pane (Message View). However, when message view is off, and I 
double-click to open a message for viewing in a new window, the 
message is not marked read for 20 seconds. I can actually open a short 
email in a new window, read it, close it, and still have to mark it 
read manually. I'd prefer to have messages marked read as soon as I 
explicitly open them.


There are lots of opinions on this subject: 
http://freron.lighthouseapp.com/projects/58672/tickets/402


I cannot make the above the default behavior, but I might make it 
optional at some point.


Note that you can bind a key to get this behavior, e.g.:

o =  ( setTag:, \\Seen, openMessages: );
\U000A = ( setTag:, \\Seen, openMessages: ); // Return
\U000D = ( setTag:, \\Seen, openMessages: ); // Enter

But you cannot override the double-click behavior.

--
Benny
___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] Messages not marked read on open

2014-10-01 Thread John Cooper



On 1 Oct 2014, at 15:27, Benny Kjær Nielsen wrote:

My preferences are set to mark messages read after 20 seconds. In 
every other mail program I've used, this setting applies only to the 
preview pane (Message View). However, when message view is off, and I 
double-click to open a message for viewing in a new window, the 
message is not marked read for 20 seconds. I can actually open a 
short email in a new window, read it, close it, and still have to 
mark it read manually. I'd prefer to have messages marked read as 
soon as I explicitly open them.


There are lots of opinions on this subject: 
http://freron.lighthouseapp.com/projects/58672/tickets/402


No doubt, but in the ticket above, there is only one contrary opinion 
other than your own. :) And while I haven't taken a full survey, I'm 
sure that the behavior of Mail, Outlook, Entourage, Gmail and Eudora 
matches what I describe—and shouldn't these count as opinions of some 
weight?


I cannot make the above the default behavior, but I might make it 
optional at some point.


Note that you can bind a key to get this behavior, e.g.:

o =  ( setTag:, \\Seen, openMessages: );
\U000A = ( setTag:, \\Seen, openMessages: ); // Return
\U000D = ( setTag:, \\Seen, openMessages: ); // Enter

But you cannot override the double-click behavior.


Thank you for the workaround. I'll set that and train myself to use a 
keybinding instead of my mouse in MailMate.


John___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] Messages not marked read on open

2014-10-01 Thread Benny Kjær Nielsen

On 1 Oct 2014, at 23:20, John Cooper wrote:

There are lots of opinions on this subject: 
http://freron.lighthouseapp.com/projects/58672/tickets/402


No doubt, but in the ticket above, there is only one contrary opinion 
other than your own. :) And while I haven't taken a full survey, I'm 
sure that the behavior of Mail, Outlook, Entourage, Gmail and Eudora 
matches what I describe—and shouldn't these count as opinions of 
some weight?


Most of those support POP3, encourage top posting, encourage the use of 
HTML, don't support `format=flowed`, etc. :-)


As a user of MailMate, your opinion counts more than the design choices 
of other email clients. Linking to the ticket was mainly to show you 
that there is little agreement on what would be the best behavior. (It 
was not my intention to put it to a vote.)


Thank you for the workaround. I'll set that and train myself to use a 
keybinding instead of my mouse in MailMate.


If you do get used to it then you might find that it was a good thing 
that the default behavior of double-clicking did not suit you.


--
Benny
___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate


Re: [MlMt] creating a smart mailbox that is choosy about attachments

2014-10-01 Thread Benny Kjær Nielsen

On 1 Oct 2014, at 12:08, Jason Davies wrote:


[background]

I thought this would be fairly straightforward but seem not to be able 
to get the logic right. This is partly because X-attachment-type 
doesn't work as I expected (I thought I could write 'docx' in there 
but that returns nothing).


You should be able to match on any header in a message, but it's tricky 
to match on a subset of a header if there is no specifier available for 
it by default.



[…]

AT this point I have tried to think how to check what you could write 
as


If attachment count is 1
and attachment name is image001.png
then exclude from smart mailbox

But I can't translate that successfully into smart mailbox rules. 
Sometimes there are multiple word docs, for instance and there may be 
a signature graphic - or not.


I'm currently trying it by having multiple smart mailboxes which is 
the only way I see to exclude things but that is also not turning out 
as I hoped...;)


I would probably need some concrete example to precisely understand what 
you are trying to do, but it's a good idea to create separate smart 
mailboxes to separate each matching issue.


It is very tricky to match on attachments for various reasons. It's 
tricky to even count the attachments as done for `Attachments-Count`. 
One thing to note is that when you try to match on headers of 
attachments (or any other subpart of a message) then you need to use the 
“All Body Parts” toggle in the comparison popup. This ensures that 
MailMate looks beyond the headers of the root headers of each message. 
But this does not cover all use cases since it's very hard to combine 
conditions for a single subpart.


--
Benny
___
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate