As I'm composing mail, mu4e automatically saves drafts to the mu4e-drafts-folder. When I send the mail, these drafts persist. I expected mu4e to delete from the folder.

I'm unable to find any documentation in the mu4e manual, and I'm afraid I'm still too new to this codebase to see how to hack together what I want.

Is there a user option to enable deletion on send? Or an obvious function I can drop into, say, message-sent-hook?

  • Can you check mu4e-sent-messages-behavior setting ? The documentation doesn't have details, but it may get you started. ---------- Which server are you using ? The behaviour you are seeing, may be due to the server, rather than client (mu4e) – Mandar Vaze May 2 '16 at 6:55
  • I have loads of drafts. Look forwarding to the solution. – yi.tang.uni May 2 '16 at 7:48
  • After some research, what happens in my case is this : when composing a new message, mu4e picks a name for saving it to disk, say draftname. But when I update-mail-and-index, the draft gets renamed (I guess offlineimap does that). So if I continue editing from the same buffer I started with, and save it again, a new file draftname is created. That file will be re-renamed again, to yet another name, and so on until you finally send the mail. So the more often you update-mail-and-index, the more drafts you get. – YoungFrog Jul 6 '16 at 9:10

If you use offlineimap (like I do) then your drafts likely accumulate because offlineimap syncs emacs' #autosave# files (kept in Drafts/cur folder). As offlineimap can only ignore files starting with '.' (and it's not configurable) the solution is to change the way draft autosaves are named:

(defun draft-auto-save-buffer-name-handler (operation &rest args)
"for `make-auto-save-file-name' set '.' in front of the file name; do nothing for other operations"  
  (and buffer-file-name (eq operation 'make-auto-save-file-name))
  (concat (file-name-directory buffer-file-name)
            (file-name-nondirectory buffer-file-name))
 (let ((inhibit-file-name-handlers
       (cons 'draft-auto-save-buffer-name-handler
             (and (eq inhibit-file-name-operation operation)
      (inhibit-file-name-operation operation))
  (apply operation args))))

(add-to-list 'file-name-handler-alist '("Drafts/cur/" . draft-auto-save-buffer-name-handler))

Other possible option would be to store all autosaves in a dedicated folder (check auto-save-file-name-transforms variable).

  • This solution works for me, and I am using mbsync instead of offlineimap. Thank you! – killdash9 Mar 8 '18 at 22:14

I have been suffering from the same problem. The solution I prefer is to disable auto-save-mode in mu4e-compose so that drafts do not accumulate.

(add-hook 'mu4e-compose-mode-hook #'(lambda () (auto-save-mode -1)))

Plus obviously, set mu4e-sent-messages-behavior to delete, as suggested by previous answers (especially in Gmail since Gamil takes care of sent messages)

(setq mu4e-sent-messages-behavior 'delete)

I like the answer above (with 0 votes; can't help, reputation = 1).

I was having exactly this problem, and didn't like the idea of temp and autosaves accumulating locally, even if offlineimap didn't sync them. What I did was prepend an rm statement to the mu4e-get-mail-command variable set in ~/.emacs.

This assumes you're using maildir format locally. So for me, with offlineimap and an otherwise typical GmailMailDir setup, this was:

(setq mu4e-get-mail-command "rm -f ~/.mail/\[Gmail\].Drafts/cur/*~ ; rm -f ~/.mail/\[Gmail\].Drafts/cur/cur/\#* ; /usr/local/bin/offlineimap -o")

in my ~/.emacs. This catches the temp files (affixed with ~) and autosaves (bracketed with #).

There are two drawbacks: 1. Your emacs buffer temp and autosaves for drafts will be deleted every time you check your mail. 2. If you have silly drafts already synced, they'll back-sync to your local repo (and not look like emacs buffer autosaves). I had to delete mine on Gmail.

If you wanted to "replicate" the better answer above in a Bash way instead of emacs, you could change this strategy to an mv instead of an rm.


You should set mu4e-sent-messages-behavior to the desired value (from the docs):

* `sent'    move the sent message to the Sent-folder (`mu4e-sent-folder')
* `trash'   move the sent message to the Trash-folder (`mu4e-trash-folder')
* `delete'  delete the sent message.

You probably want to do (setq mu4e-sent-messages-behavior 'sent), unless you use Gmail, in which case you want 'delete.

  • 1
    I have it set to sent but that does not help. The question is about drafts that tend to accumulate. – YoungFrog Jun 21 '16 at 8:38
  • @YoungFrog: that's exactly your answer (assuming no other issues). Setting mu4e-sent-messages-behavior to sent is supposed to move the draft to the sent folder, i.e. there should be no draft left. – Arthur Jun 22 '16 at 9:48
  • @YoungFrog: Are you actually referring to the autosave drafts (i.e. the autosave copies made by emacs of the drafts)? They have filesnames like #0123456789.0123456789abcdef.mycomputer,U=90:2,DS#. This has nothing to do with mu. – Arthur Jun 22 '16 at 9:51
  • My sent messages go to the Sent folder, no problem, but then I also have a ton of "intermediate steps" draft messages that accumulate : say I'm writing a long message, then I'll probably get one draft with only the first few lines, then another draft with some more lines, and yet another almost-final version. Only the true final version that I actually send is moved to the Sent folder (as it should) but I claim the intermediate partial messages should not be there, and I think that's what the question is about. I don't think they are autosaves (I just checked the filenames). – YoungFrog Jun 22 '16 at 12:57
  • @YoungFrog: Oh, I see what you're asking now. Maybe you want to copy parts of your comment back to your original question, because it wasn't clear to me this was what you were referring to. [Additionally, I think you should make it clear that this has nothing to do with sending; these intermediate drafts appear even before you send the final copy, and I don't they they should.] – Arthur Jun 23 '16 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.