Drafts management is really limited and not secure, a refactor is needed.
/tmp to [XDG_DATA_HOME](https://wiki.archlinux.org/title/XDG_Base_Directory)/himalaya/<account>.Bounty: 1250 €
Would be a good idea to save to the Draft mailbox, if any. So it syncs across devices too.
As precedent, Fastmail, Apple Mail and Neomutt all do this. Not sure if neomutt did it by default or if I had to configure it.
I think I would make this configurable, with a fallback to
$XDG_DATA_HOME/himalaya/drafts.
It is true that saving drafts to the Drafts folder directly solves the matter, and it enables the ability to save more than one draft. But then we need a way to edit those drafts, and I realize that we miss an edit command (literally read a raw email and put it in your editor).
I think I would make this configurable, with a fallback to
$XDG_DATA_HOME/himalaya/drafts.Saving drafts to Drafts folder is way enough, I do not see the point of saving locally anymore.
I do not see the point of saving locally anymore.
You're still saving locally, just into the mailbox itself (e.g.: via Maildir). You can't save the draft straight into an IMAP Mailbox; to do that you'd have to tell $EDITOR to open something like
imap://draft/my-draft.Which bring about another point: if there is only a non-filesystem mailbox available, the fallback also has to be something like
$XDG_DATA_HOME/himalaya/drafts.
You're still saving locally, just into the mailbox itself (e.g.: via Maildir).
It depends on the backend:
You can't save the draft straight into an IMAP Mailbox; to do that you'd have to tell $EDITOR to open something like
imap://draft/my-draft.Yes you can using the
savecommand. But the responsibility moves to the UI: when you save your buffer it should remove the actual draft and create a new one usingsave.
Yes you can using the save command. But the responsibility moves to the UI: when you save your buffer it should remove the actual draft and create a new one using save.
I'm not sure I follow. I run
himalaya write, and that basically runs$EDITOR $FILE.$FILEmust be a filesystem path, or the editor won't be able to access it. Synchronizing to IMAP is possible, but that's a separate process (e.g.: you'd need to use something likeinotifyto determine each time that the editor has saved the file to push it to the IMAP remote).
My bad, I mixed up things. Indeed you need to have a local path for storing draft (in term of buffer) of real drafts (in term of email). I was talking about the post edition choice, but it is not relevant here!
There is no more bounty for this task.