~soywod/pimalaya#11: 
Improve drafts management

Drafts management is really limited and not secure, a refactor is needed.


#email-lib

  • Move local drafts from /tmp to XDG_DATA_HOME/himalaya/.
  • Make drafts name unique so users can have multiple of them.
  • Add option to encrypt local drafts.
  • Add ability to "edit" a remote draft. Such feature does not exist on IMAP server, so it can technically be done by consuming (deleting) the targeted draft then to save it back.

#himalaya

  • Add ability to choose between multiple local drafts before editing.
  • Add config option to enable local draft encryption.
  • Add ability to edit a draft, then to either save or send it.

#himalaya-vim

  • Add ability to edit a draft, then to either save or send it.
Status
REPORTED
Submitter
~soywod
Assigned to
No-one
Submitted
1 year, 7 months ago
Updated
4 months ago
Labels
1:email-lib 2:himalaya 3:cli 3:vim

~soywod 1 year, 5 months ago

Bounty: 1250 €

~whynothugo 1 year, 3 months ago

Would be a good idea to save to the Draft mailbox, if any. So it syncs across devices too.

~whynothugo 1 year, 3 months ago

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.

~whynothugo 1 year, 3 months ago

I think I would make this configurable, with a fallback to $XDG_DATA_HOME/himalaya/drafts.

~soywod 1 year, 3 months ago

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).

~soywod 1 year, 3 months ago

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.

~whynothugo 1 year, 3 months ago

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.

~soywod 1 year, 3 months ago

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 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.

~whynothugo 1 year, 3 months ago

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. $FILE must 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 like inotify to determine each time that the editor has saved the file to push it to the IMAP remote).

~soywod 1 year, 3 months ago

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!

~soywod 1 year, 1 month ago

There is no more bounty for this task.

Register here or Log in to comment, or comment via email.