Freron MailMate

Comments and changes to this ticket

• You flagged this item as spam.
  

  Mike K June 20th, 2013 @ 08:04 PM

  • no changes were found...
• 

  benny June 21st, 2013 @ 02:53 PM

  • State changed from “new” to “accepted”

  Sorry for the late answer. It just means I did not have any straightforward answers.

  Users seem to have very differing expectations/uses of the read state of a message. For some users disabling “marking as read automatically” means that they want complete control over when messages are marked as read. Although items 1-3 make sense then they do not want that (or maybe only a subset).

  I assume you do not want to disable the display of a message in the main window which would otherwise allow you enable “marking as read automatically”.

  The straightforward solution would be to have additional options like:

  Always mark a message as read when: [ ] Opening in separate window [ ] Replying [ ] Forwarding [ ] Clicking on a link

  Maybe also “scrolling to the end”. But I would really like to find a more elegant or general solution.

  A future version of MailMate is probably going to allow one to run scripts triggered by various events. This could include all of the events above and this would allow any action to be taken when, e.g., replying to a message, including marking the replied message as read.

  In other words, I'll have to think more about this. I'll mark the ticket as “accepted” in the sense that I am willing to find a way to solve your problem.

  Other users are welcome to add comments about what they would expect to be the default behavior.

  Note: Item 3 on your list could be done using custom key bindings.

• You flagged this item as spam.
  

  Eric A. Meyer July 5th, 2013 @ 03:20 PM

  By default, I would expect a message to be marked read upon reply or forwarding. Probably not clicking on a link, since one could click a link at the beginning of a long message without having read the rest, or click a link by accident. Certainly not opening in a new window, which could also happen by accident, and also because an open window might be ignored for a very long time and possibly forgotten through a quit or crash or what-have-you.

  Personally, I’m VERY interested to know how custom keybindings could substitute for item 3 (“It has been forwarded or replied to.”). I tried to figure it out at one point and failed.

• 

  benny July 5th, 2013 @ 10:13 PM

  @eric: This emphasizes that users have different expectations of auto-read behavior. Item 3 can be done as follows:

  "x" = ( 'setTag:', '\\Seen', 'reply:');
  "y" = ( 'setTag:', '\\Seen', 'forwardMessage:');
  

• You flagged this item as spam.
  

  Eric A. Meyer July 8th, 2013 @ 07:36 PM

  Yeah, I figured my input would provide such an emphasis. The preference approach really seems to make the most sense.

  Can the same be done as a filter or other non-keyboard action? It would be a lot handier to hook the mark-as-read behavior into the sending of a reply (as opposed to the beginning of a reply composition); ditto for forwarding. Otherwise I have to write new bindings for Reply Sender, Reply All, Reply List, and Forward, which is kind of inefficient.

  If not, I can live with keyboard solution, assuming I can properly override the built-in keys.

• You flagged this item as spam.
  

  Mike K July 8th, 2013 @ 10:41 PM

  • no changes were found...
• 

  benny July 9th, 2013 @ 12:58 PM

  Ok, this is going in two different directions.

  @eric: Your problem would be solved by mailbox rules although my current implementation does not offer a way to apply an action to a parent message (the replied message). I'll have to give that some thought, but I'll solve it somehow. And I should then also add it as rules enabled by default.

  @mike: Technically, the solution with detailed options is not a problem, but it's a bit of a mess. “Scrolling to the end” is hard to define (think about a short message). Returning to your original request I've already promised a solution to item 3 and I'm willing to make item 1 a GUI option. Item 2 might be doable with a future version of the rules system, but I'm not quite ready to share details on that yet.

• You flagged this item as spam.
  

  Mike K July 15th, 2013 @ 08:25 PM

  • no changes were found...

• You flagged this item as spam.
  

  Rob McBroom November 11th, 2013 @ 07:06 PM

  I’d like to add a sub-request: Toolbar buttons for marking read/unread.

  I use them heavily in other clients …but maybe that’s only because the automatic behavior is always “wrong”. :-)

• You flagged this item as spam.
  

  Mike K January 18th, 2017 @ 10:29 PM

  Four years later, this is still a problem. I am getting very upset with the developer's refusal to fix bugs in this very expensive program.

  MailMate lies and tells me that read emails are unread, that replied-to emails are unread. Then, randomly, later on, if I happen to open them a second or third time, they suddenly flip to read or replied... in exactly the manner Eric complained that he doesn't want to see, except, now, instead of at least happening at the point when the email is read or replied, which would at least make a little sense, it only happens if and when you happen to re-open the email at some later point.

  The bugs and poor design here are atrocious.

  There's now a keystroke to mark emails read - the finger-bending and completely unmemorable command-shift-U - which, since I've been using it, has proven to be a completely unacceptable answer, as I have to remember to update each and every email's status manually once I have read it. That's just stupid.

  Email programs should never tell me an email is unread after I have read it. Giving users false information is a cardinal sin in programming, it's ridiculous, and every other email app developer in the last 45 years has somehow managed to get this basic design precept right. This is getting stupid at this point. It's been FOUR YEARS with no fix for this incredibly important, fundamental bug.

  Please. MailMate should not lie to users. That's execrable design, and it reflects very poorly on all sorts of things that you as a commercial app developer really might want to consider becoming concerned about.

• 

  benny January 18th, 2017 @ 10:58 PM

  @Mike: You have already publicly shamed me in tickets #1560 and #1419. I refer any readers of this ticket to my replies in the other tickets. Here I'll just repeat that I understand your frustration, but enough is enough. Please, let me get back to work (tomorrow).