Freron MailMate

Comments and changes to this ticket

• You flagged this item as spam.
  

  Mika Raunio January 21st, 2013 @ 10:33 PM

  Another vote for this, especially number IV. Flag as \Deleted then manually expunge (usually after I'm done with a bunch of messages) is what I've been doing every day for over ten years, and everything else feels "wrong".

• 

  benny January 22nd, 2013 @ 08:46 AM

  • State changed from “new” to “accepted”

  Not sure why I never replied to the original ticket, but this is the current state of affairs:

  I. Now possible by holding down ⌥ when deleting a message.
  II. A suppress check mark button is now part of the alert.
  III. Not yet implemented.
  IV.

  A. Possible using a custom key binding to set the \Deleted flag. (Or create a tag for it, but then it's displayed in the headers view.)
  B. MailMate displays \Deleted messages with a red dot in the read/unread column.
  C. 1-3. Not yet implemented.

  The main priority would be to implement C3, i.e., provide a method to expunge \Deleted messages. III is a medium priority and C1-2 are low-priority (although C1 is probably easy when C3 is implemented).

• 

  benny January 25th, 2013 @ 11:20 AM

  Some corrections/additions:

  IV. B.: This only worked for IMAP mailboxes. Mailboxes based on “All Messages” do not show messages marked as deleted. I had forgotten this difference in behavior and it does not make a lot of sense. It would be better with some kind of show/hide option, but it's a bit complicated.

  For the next update I've implemented C3, for example, one can bind 0 to the expunge command like this:

  "0" = "expungeDeletedMessages:";
  

  It'll actually not expunge an IMAP mailbox in the classic sense (just using the IMAP EXPUNGE command). It just takes all messages marked with \Deleted in the currently displayed mailbox/search and delete them without moving to the trash (as if holding down ⌥ when deleting). The result is the same, but it is more flexible.

  I've also put in a quick hack to enable the display of deleted messages in all mailboxes:

  defaults write com.freron.MailMate MmShowDeletedMessages -bool YES
  

  I'll need to refactor how this works before making any of it a GUI setting, but you can use it to see if it works as expected.

• You flagged this item as spam.
  

  Justin October 30th, 2013 @ 12:11 AM

  My two cents on this request:

  I would like to have the default "delete" behavior differ between accounts. (N.B. I don't know for sure which of \UF728 or \U007F I mean - I am referring to the 'delete' key on modern Mac keyboards, whose unmodified behavior in text fields is delete-to-the-left.) Four different use cases, drawn from four different accounts I use:

  • All mail is pushed into a 'received-mail' folder by procmail before it hits the inbox. I would like the "delete" key to mark messages as deleted and immediately expunge them (or equivalent behavior, however it is implemented) without a Trash folder involved.
  • Auto-learning of "ham" messages is handled on the server by looking for flagged-as-deleted messages older than some timeout, learning those messages, and expunging them. I would like the "delete" key to mark messages as deleted and not expunge them.
  • I never want to 'delete' a message in Gmail. I'm using the latest test build with the "All Mail" workaround, and setting "All Mail" to the Deleted Items folder, at the moment - but that seems hacky, and I don't really want All Mail subscribed anyway - it gets a lot of random stuff that I want to keep around but basically never want to read. I don't care what the 'delete' key does to implement it, but I would like it to archive that gmail account's messages and not require All Mail to be subscribed.
  • I want the (currently default) "Move to Trash" behavior when I hit delete.

  I can, I believe, handle the second and third desires by binding the delete key to setTag: \Deleted, since Google has an option to immediately expunge and archive when you set Deleted - but there's no way that I am aware of to change it up based on the source account, and I don't see how to bind a key to "delete without moving to Trash", if it is indeed possible.

  (It is to your and MailMate's great credit that this inconvenience is the only issue I've run into thus far - six hours into my trial - and that's at least an exaggerated order of magnitude better than every other mail client I've tried.)

• 

  benny October 30th, 2013 @ 10:26 AM

  @justin: That's quite a list of alternative behaviors. I'll keep this in mind for settings on a mailbox/account level. The trickiest part is probably Gmail. Disregarding that one then you would like the following options for delete key behavior:

  Move to Deleted Messages (current behavior)
  Mark as Deleted (set \Deleted flag)
  Delete Now (set \Deleted flag and expunge)
  

  And for Gmail accounts:

  Move to All Mail
  

  Maybe that last one should just be:

  Archive (move to the assigned Archive mailbox)
  

  And then some hidden setting to tell MailMate to do this for Gmail accounts even if All Mail is not synchronized.

• You flagged this item as spam.
  

  Justin October 30th, 2013 @ 04:01 PM

  That sounds like the right set of options. As I said, the gmail-specific behavior is not necessary for the moment, since gmail has an option to treat set \Deleted flag as expunge immediately and archive - so if it will significantly reduce the complexity to ignore gmail for the moment, I'm all in favor.

• You flagged this item as spam.
  

  Pete July 22nd, 2015 @ 01:05 PM

  Looks like this ticket hasn't been updated in a while, but I've got a slight revision to suggest for it: In addition to all of the above, I also do not want the mailbox expunged when I have moved a message to a different mailbox. So really, I just want a config for "Do not expunge except explicitly". Shall I put in a new request for that, or is it OK in this ticket?

• You flagged this item as spam.
  

  Bill Cole July 22nd, 2015 @ 03:12 PM

  In addition to all of the above, I also do not want the mailbox expunged when I have moved a message to a different mailbox. So really, I just want a config for "Do not expunge except explicitly". Shall I put in a new request for that, or is it OK in this ticket?

  It may be necessary to put that request in with whatever the IETF is currently calling the working group on IMAP standards.

  The classical way to move a message between IMAP mailboxes is a 3-step process: copy the message to its new home, set the \Deleted flag on the source message, and expunge either the whole mailbox (maybe after temporarily removing \Deleted from other messages) or (if the UIDPLUS extension is present) just the source message. In that case it is possible to omit the last step, but there's a catch: many IMAP implementations (including Courier, Dovecot, and GMail) can be set to auto-expunge a mailbox on an implicit close (i.e. selection or examination of another mailbox or logout) even if the CLOSE or EXPUNGE commands (which MUST expunge the mailbox) are not issued. Hence there is an intermediate state in the logical move where there are 2 messages in 2 mailboxes with one marked \Deleted and a client can attempt to preserve that state by inaction, and yet the \Deleted message may still vanish from the source mailbox.

  Complicating matters further is the MOVE extension, which makes movement of messages between mailboxes an atomic action. Given the way IMAP works with multiple concurrent access to accounts and mailboxes and asynchronous command execution, this is a useful simplification for clients. If MM uses the MOVE commands to move messages, there is no intermediate state available to preserve.

  In short form: Depending on the policies & configuration of your IMAP server it may not be possible for such a feature to actually work as desired and depending on how much Benny has optimized MM's behavior based on extension availability it may impact performance to have such a feature switched on.

• You flagged this item as spam.
  

  Pete July 22nd, 2015 @ 05:37 PM

  I am not concerned about messages getting auto-expunged. First of all, servers can expunge for all sorts of reasons that 3501 doesn't prevent, so you can't depend on an expunge not happening behind your back. I can live with that. But in my case, it's my (Dovecot) server and I can configure it not to do implicit closes, and I trust Dovecot not to do arbitrary expunges.

  MOVE (6581) is a different issue. If Benny has implemented that, I'll probably be OK with it, as the behavior is much more predictable. I'm pretty sure my current version of Dovecot doesn't support it.

• 

  benny March 22nd, 2018 @ 02:24 PM

  • State changed from “accepted” to “fixcommitted”

  @Pete: For the record, MailMate does use MOVE when available.

  I believe most of what is described in this ticket is possible now (in the latest test release). Please create new tickets for any specific changes/additions.

  See the new features described here.

• 

  benny April 9th, 2018 @ 12:05 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]