mu4e: cancelled drafts not removed
James Ladan
James Ladan
Dirk-Jan C. Binnema
I can make mu4e a bit less eager to save drafts (this is not as easy as
it sounds though, but I'll spare you the details :)
However, that does not solve the second problem; i.e.. GMail/offlineimap
do not like the draft messages generated by Gnus' message-mode (which
mu4e uses). I'll need to check what we can do there.
Best wishes,
Dirk.
--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
James Ladan
I can make mu4e a bit less eager to save drafts (this is not as easy as
it sounds though, but I'll spare you the details :)
However, that does not solve the second problem; i.e.. GMail/offlineimap
do not like the draft messages generated by Gnus' message-mode (which
mu4e uses). I'll need to check what we can do there.
Dirk-Jan C. Binnema
On Mon 26 Mar 2012 11:57:34 PM EEST, James Ladan wrote:
> On Monday, 26 March 2012 13:03:41 UTC-7, djcb wrote:
> >
> > I can make mu4e a bit less eager to save drafts (this is not as easy as
> > it sounds though, but I'll spare you the details :)
> >
> :)
I've implemented something, and pushed it. mu4e should now no longer
automatically save your messages, wait for you to explicitly do so. Hope
this cuts down on the number of stale draft files...
I've also found something that may cause your problems with
`mu4e-headers-leave-behavior'; possibly, the back-end was quit before it
got the chance to get rid of the messages. Anyway, it might be fixes
now.
> > However, that does not solve the second problem; i.e.. GMail/offlineimap
> > do not like the draft messages generated by Gnus' message-mode (which
> > mu4e uses). I'll need to check what we can do there.
> >
> I'm personally not in any sort of rush on that. I only recently switched
> from POP3 to IMAP, so I'm used to drafts only being on one machine.
You could also using another folder for drafts of course. Or exclude it
for syncing.
> As a counter to all these little things I've stumbled on, I would like to
> note that I love mu4e. Thank you very much for creating it!
Thanks a lot :) It's fun to work on mu4e, and it's fun to make it a
little bit better all the time.
James Ladan
Hi James,On Mon 26 Mar 2012 11:57:34 PM EEST, James Ladan wrote:
> On Monday, 26 March 2012 13:03:41 UTC-7, djcb wrote:
> > I can make mu4e a bit less eager to save drafts (this is not as easy as
> > it sounds though, but I'll spare you the details :)
I've implemented something, and pushed it. mu4e should now no longer
automatically save your messages, wait for you to explicitly do so. Hope
this cuts down on the number of stale draft files...
I've also found something that may cause your problems with
`mu4e-headers-leave-behavior'; possibly, the back-end was quit before it
got the chance to get rid of the messages. Anyway, it might be fixes
now.
You could also using another folder for drafts of course. Or exclude it for syncing.
James.
Dirk-Jan C. Binnema
On Thu 29 Mar 2012 12:00:34 AM EEST, James Ladan wrote:
> The stale draft files are gone, but now there's an error when I send and
> sent email isn't saved. Maybe save some near-term grief and procrastinate
> on it until post-0.9.8.3? :)
Nah :) It's included now, and I'll make sure it will work correctly in
0.9.8.3. Thank you for your efforts in getting us there!
> 2012-03-28 12:39:58 -> sent
> /home/james/Mail/Drafts/cur/20120328-449a12813d56e072e9e5.malbec:2,D /Drafts
> 2012-03-28 12:39:58 * Received 124 byte(s)
> 2012-03-28 12:39:58 <- (:error 11 :error-message "failed to add path
> '/home/james/Mail/Drafts/cur/20120328-449a12813d56e072e9e5.malbec:2,D'")
>
> If I explicitly save the buffer before sending, there's no problem.
Actually, I noticed that problem today, and it *should* be fixed already
in git-master.
> I've also found something that may cause your problems with
> > `mu4e-headers-leave-behavior'; possibly, the back-end was quit before it
> > got the chance to get rid of the messages. Anyway, it might be fixes
> > now.
> >
> Seems like it mostly works, but now there's an error at the end:
>
> error in process filter: save-current-buffer: Selecting deleted buffer
> error in process filter: Selecting deleted buffer
>
> Turning "debug-on-error" on, the backtrace is:
>
> Debugger entered--Lisp error: (error "Selecting deleted buffer")
[snip]
Ah, it seems mu4e tries to update a buffer that's already dead. I pushed
some changes for this (basically, check first if the buffer's still alive).
> > You could also using another folder for drafts of course. Or exclude
> > it for syncing.
> >
> Yeah, I've just excluded it for syncing -- it would be a minor nicety to
> have saved drafts synced, but it seems like there are a lot of
> complications. For instance, if I've saved the draft buffer and offlineimap
> comes along and syncs it and renames it due to communications with the
> server, mu would have to notice and inform mu4e which would have to rename
> the buffer or at least make sure it's still pointing at the correct file...
>
> Do you know what the convention is for the "tmp" directory in a maildir?
> One thought I had was:
> - begin a draft; work is saved in drafts/tmp
> - send it: move it from drafts/tmp -> sent/cur
> - postpone it: move it from drafts/tmp -> drafts/cur (replacing "--text
> follows this line--" with a blank line) and close the buffer
tmp/ is something that mu4e doesn't use, but is specified in the Maildir
standard for safety - basically, a mailserver would write a message to
tmp/ first, and only when it has been written there correctly, rename it
to something in cur/.
See: http://cr.yp.to/proto/maildir.html
James Ladan
> On Thu 29 Mar 2012 12:00:34 AM EEST, James Ladan wrote:
>
> > The stale draft files are gone, but now there's an error when I send and
> > sent email isn't saved. Maybe save some near-term grief and
> > procrastinate
> > on it until post-0.9.8.3? :)
>
> Nah :) It's included now, and I'll make sure it will work correctly in
> 0.9.8.3. Thank you for your efforts in getting us there!
:)
> > 2012-03-28 12:39:58 -> sent
> > /home/james/Mail/Drafts/cur/20120328-449a12813d56e072e9e5.malbec:2,D
> > /Drafts
> > 2012-03-28 12:39:58 * Received 124 byte(s)
> > 2012-03-28 12:39:58 <- (:error 11 :error-message "failed to add path
> > '/home/james/Mail/Drafts/cur/20120328-449a12813d56e072e9e5.malbec:2,D'")
> >
> > If I explicitly save the buffer before sending, there's no problem.
>
> Actually, I noticed that problem today, and it *should* be fixed already
> in git-master.
Hmm. I still seem to have the problem after updating, installing, and
restarting emacs.
> Ah, it seems mu4e tries to update a buffer that's already dead. I pushed
> some changes for this (basically, check first if the buffer's still
> alive).
Confirmed -- works for me. :)
> > Do you know what the convention is for the "tmp" directory in a maildir?
> > One thought I had was:
> > - begin a draft; work is saved in drafts/tmp
> > - send it: move it from drafts/tmp -> sent/cur
> > - postpone it: move it from drafts/tmp -> drafts/cur (replacing "--text
> > follows this line--" with a blank line) and close the buffer
>
> tmp/ is something that mu4e doesn't use, but is specified in the Maildir
> standard for safety - basically, a mailserver would write a message to
> tmp/ first, and only when it has been written there correctly, rename it
> to something in cur/.
>
> See: http://cr.yp.to/proto/maildir.html
So possibly a legitimate use... Or, since other directories are
permitted, maybe drafts/.mu4e?
Thanks,
James.
Dirk-Jan C. Binnema
On Thu 29 Mar 2012 04:00:37 AM EEST, James Ladan wrote:
> Hmm. I still seem to have the problem after updating, installing, and
> restarting emacs.
Mmmmm... can you check what's in the backtrace ('mu4e-debug' etc.) this
time?
> > Ah, it seems mu4e tries to update a buffer that's already dead. I
> > pushed some changes for this (basically, check first if the buffer's
> > still alive).
>
> Confirmed -- works for me. :)
Good! Thanks for checking.
> > > Do you know what the convention is for the "tmp" directory in a
> > > maildir? One thought I had was: - begin a draft; work is saved in
> > > drafts/tmp - send it: move it from drafts/tmp -> sent/cur -
> > > postpone it: move it from drafts/tmp -> drafts/cur (replacing
> > > "--text follows this line--" with a blank line) and close the
> > > buffer
> >
> > tmp/ is something that mu4e doesn't use, but is specified in the
> >Maildir standard for safety - basically, a mailserver would write a
> >message to tmp/ first, and only when it has been written there
> >correctly, rename it to something in cur/.
> >
> > See: http://cr.yp.to/proto/maildir.html
>
> So possibly a legitimate use... Or, since other directories are
> permitted, maybe drafts/.mu4e?
Hmm, what would the semantics of drafts/.mu4e/ be?
Note, you can just create another maildir (e.g. with 'mu mkdir'), say
"MyDrafts", and set mu4e-drafts-folder to that and simply not sync that
with Gmail.
James Ladan
>> Hmm. I still seem to have the problem after updating, installing, and
>> restarting emacs.
>
> Mmmmm... can you check what's in the backtrace ('mu4e-debug' etc.) this
> time?
I didn't include it because it looked the same as last time. I should
have said that explicitly.
2012-03-29 10:32:05 -> sent
/home/james/Mail/Drafts/cur/20120329-3c3a11ec33b7e1422ed.malbec:2,D
/Drafts
2012-03-29 10:32:05 * Received 123 byte(s)
2012-03-29 10:32:05 <- (:error 11 :error-message "failed to add path
'/home/james/Mail/Drafts/cur/20120329-3c3a11ec33b7e1422ed.malbec:2,D'")
>> > > Do you know what the convention is for the "tmp" directory in a
>> > > maildir? One thought I had was: - begin a draft; work is saved in
>> > > drafts/tmp - send it: move it from drafts/tmp -> sent/cur -
>> > > postpone it: move it from drafts/tmp -> drafts/cur (replacing
>> > > "--text follows this line--" with a blank line) and close the
>> > > buffer
>> >
>> > tmp/ is something that mu4e doesn't use, but is specified in the
>> >Maildir standard for safety - basically, a mailserver would write a
>> >message to tmp/ first, and only when it has been written there
>> >correctly, rename it to something in cur/.
>> >
>> > See: http://cr.yp.to/proto/maildir.html
>>
>> So possibly a legitimate use... Or, since other directories are
>> permitted, maybe drafts/.mu4e?
>
> Hmm, what would the semantics of drafts/.mu4e/ be?
>
> Note, you can just create another maildir (e.g. with 'mu mkdir'), say
> "MyDrafts", and set mu4e-drafts-folder to that and simply not sync that
> with Gmail.
My thought was that an email stored in drafts/cur should be
well-formed, since it could be synchronized with an IMAP server -- so
it seems the "--text follows this line--" should not be there.
If an intermediate form of the draft is to be saved which does include
this line, it should go somewhere other than drafts/cur. Hence the
idea that the file would be "drafts/.mu4e/123ABC" so that a C-x C-s
wouldn't save the version with "--text follows this line--" into cur.
Or rather than storing the initial stage of a draft in a different
directory, would it be possible (and simpler) for the file to always
be displayed with the "--text follows this line--" line but not
include that line in the actual contents written to disk?
Again, I would vote for this to be down near the bottom of the list of
priorities, since the work-around is so easy, and at least to me,
syncing drafts isn't all that important.
Dirk-Jan C. Binnema
On Thu 29 Mar 2012 08:56:24 PM EEST, James Ladan wrote:
> > Mmmmm... can you check what's in the backtrace ('mu4e-debug' etc.) this
> > time?
>
> I didn't include it because it looked the same as last time. I should
> have said that explicitly.
Ah -- I finally was able to reproduce it; and fix it. So hopefully it's
fixed for you now as well.
While testing I also found that searching for Gmail folder names
(maildirs) was rather broken; that's fixed now as well. Note, you'll
need a 'mu index --rebuild'.
> > Hmm, what would the semantics of drafts/.mu4e/ be?
> >
> > Note, you can just create another maildir (e.g. with 'mu mkdir'), say
> > "MyDrafts", and set mu4e-drafts-folder to that and simply not sync that
> > with Gmail.
>
> My thought was that an email stored in drafts/cur should be
> well-formed, since it could be synchronized with an IMAP server -- so
> it seems the "--text follows this line--" should not be there.
>
> If an intermediate form of the draft is to be saved which does include
> this line, it should go somewhere other than drafts/cur. Hence the
> idea that the file would be "drafts/.mu4e/123ABC" so that a C-x C-s
> wouldn't save the version with "--text follows this line--" into cur.
>
> Or rather than storing the initial stage of a draft in a different
> directory, would it be possible (and simpler) for the file to always
> be displayed with the "--text follows this line--" line but not
> include that line in the actual contents written to disk?
>
> Again, I would vote for this to be down near the bottom of the list of
> priorities, since the work-around is so easy, and at least to me,
> syncing drafts isn't all that important.
Yeah; I'll check if I can somehow get rid of the text-follows-this-line
when saving messages. It's an artifact of Gnu's message-mode (which mu4e
re-uses), but I think I could make it go away when writing (this is
easy). Slightly harder (but not much) is adding it again when editing
draft messages.
James Ladan
On Fri, Mar 30, 2012 at 09:13, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
> Ah -- I finally was able to reproduce it; and fix it. So hopefully it's
> fixed for you now as well.
Perfect, thanks!
> While testing I also found that searching for Gmail folder names
> (maildirs) was rather broken; that's fixed now as well. Note, you'll
> need a 'mu index --rebuild'.
I should take a look at setting up my Gmail account set up for use with mu4e. :)
> Yeah; I'll check if I can somehow get rid of the text-follows-this-line
> when saving messages. It's an artifact of Gnu's message-mode (which mu4e
> re-uses), but I think I could make it go away when writing (this is
> easy). Slightly harder (but not much) is adding it again when editing
> draft messages.
I just did what I should have done before making any suggestions and
gave Wanderlust a try. Seems it takes the approach of stripping out
that line and somehow putting it back in when editing the draft. Where
it fails is that if an update runs while the draft is being edited,
the name of the file on disk gets renamed, and the initial blank draft
message gets left behind when the message is sent.
Thanks,
James.
Dirk-Jan C. Binnema
On Fri 30 Mar 2012 08:46:55 PM EEST, James Ladan wrote:
> > Yeah; I'll check if I can somehow get rid of the text-follows-this-line
> > when saving messages. It's an artifact of Gnu's message-mode (which mu4e
> > re-uses), but I think I could make it go away when writing (this is
> > easy). Slightly harder (but not much) is adding it again when editing
> > draft messages.
>
> I just did what I should have done before making any suggestions and
> gave Wanderlust a try. Seems it takes the approach of stripping out
> that line and somehow putting it back in when editing the draft. Where
> it fails is that if an update runs while the draft is being edited,
> the name of the file on disk gets renamed, and the initial blank draft
> message gets left behind when the message is sent.
Ah; I implemented something similar in mu4e now (pushed to git); the
"--text follows this line--" is a buffer-only thing now that should
never appear in the written file. It seems to work well for me, please
let me know if you find any problems.
Also, some small things:
- if you have set a message-signature, it will now automatically be
inserted in new messages.
- new messages are now considered unmodified until the user actual
does something with it. Thus, if you accidentally start a new
message, you can kill the buffer without emacs bothering you
James Ladan
On Sat, Mar 31, 2012 at 07:41, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
> Ah; I implemented something similar in mu4e now (pushed to git); the
> "--text follows this line--" is a buffer-only thing now that should
> never appear in the written file. It seems to work well for me, please
> let me know if you find any problems.
Finally updated and tested. Works well, thanks.
Now some new issues (because drafts are a big pain in the neck with
their edge cases, etc.):
1. If one saves a draft and an update runs in the background, the file
will likely be renamed. When the email is sent, the sent email is
correctly moved to the sent folder, but the earlier saved copy will be
left behind in the drafts folder.
2. Flags get out of whack for unseen drafts
- If I postpone a draft, let a sync run, and then try to edit, I'm
told that "Editing is only allowed for draft messages."
- If I postpone a draft, edit it, postpone it again, and then let a
sync run, I am able to open the draft for editing again later. (Good.)
- If I postpone a draft, view it, then let a sync run, I am still
able to open the draft for editing again later. (Good.)
Looks like the draft needs to be flagged as having been seen. Either a
limitation in offlineimap or the IMAP server my company uses.
In the working cases for #2, editing and sending the postponed draft
from a different computer (or webmail interface) works. Nice!
> - new messages are now considered unmodified until the user actual
> does something with it. Thus, if you accidentally start a new
> message, you can kill the buffer without emacs bothering you
Works well. :)
Thanks,
James.
Dirk-Jan C. Binnema
On Fri 06 Apr 2012 12:44:40 AM EEST, James Ladan wrote:
> Hi Dirk,
>
> On Sat, Mar 31, 2012 at 07:41, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
> > Ah; I implemented something similar in mu4e now (pushed to git); the
> > "--text follows this line--" is a buffer-only thing now that should
> > never appear in the written file. It seems to work well for me, please
> > let me know if you find any problems.
>
> Finally updated and tested. Works well, thanks.
Ah, that's good to hear.
> Now some new issues (because drafts are a big pain in the neck with
> their edge cases, etc.):
>
> 1. If one saves a draft and an update runs in the background, the file
> will likely be renamed. When the email is sent, the sent email is
> correctly moved to the sent folder, but the earlier saved copy will be
> left behind in the drafts folder.
>
> 2. Flags get out of whack for unseen drafts
> - If I postpone a draft, let a sync run, and then try to edit, I'm
> told that "Editing is only allowed for draft messages."
Drafts get the maildir 'D' flag (,D in their filename) to signify
their draftness. However, I don't think the 'D' is widely used, so
possibly the synchronization loses it. mu4e insists on that flag to
prevent users from editing existing, non-draft messages.
> - If I postpone a draft, edit it, postpone it again, and then let a
> sync run, I am able to open the draft for editing again later. (Good.)
> - If I postpone a draft, view it, then let a sync run, I am still
> able to open the draft for editing again later. (Good.)
>
> Looks like the draft needs to be flagged as having been seen. Either a
> limitation in offlineimap or the IMAP server my company uses.
Hmm, not sure what's happening... but now (git), drafts are marked as
'S' (seen). Which makes sense, I suppose, since when you save the draft,
you must have seen it. Does that fix the problem?
> In the working cases for #2, editing and sending the postponed draft
> from a different computer (or webmail interface) works. Nice!
>
> > - new messages are now considered unmodified until the user actual
> > does something with it. Thus, if you accidentally start a new
> > message, you can kill the buffer without emacs bothering you
>
> Works well. :)
Sounds great! Thanks for testing!
James Ladan
On Thu, Apr 5, 2012 at 15:33, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
> On Fri 06 Apr 2012 12:44:40 AM EEST, James Ladan wrote:
>> 2. Flags get out of whack for unseen drafts
>> - If I postpone a draft, let a sync run, and then try to edit, I'm
>> told that "Editing is only allowed for draft messages."
>
> Drafts get the maildir 'D' flag (,D in their filename) to signify
> their draftness. However, I don't think the 'D' is widely used, so
> possibly the synchronization loses it. mu4e insists on that flag to
> prevent users from editing existing, non-draft messages.
Yes, the problem was that uD was being changed to uN by either
offlineimap or my IMAP server. If the draft starts out as SD, the
flags are left alone (and propagate to any other machine that's
syncing the drafts folder).
> Hmm, not sure what's happening... but now (git), drafts are marked as
> 'S' (seen). Which makes sense, I suppose, since when you save the draft,
> you must have seen it. Does that fix the problem?
Yep! Thanks!
Cheers,
James
