I'd need to read the code to be sure, but I suspect that the intention is that the existing draft is deleted as soon as you start editing it.  Intention and reality often differ, though, and I know we have many cases where drafts that should have been deleted aren't.  I may be wrong about that, though.

In any event, if you want to save a draft message, regardless of its current state, use the "Close and save" button, which usually works (bug #747627).

hi

i do not agree that a draft should be deleted as soon as opened for editing. I've used many email clients, and none that i've used behave that way. 

that would be like, if you open a text document on your hard drive to edit it, then the copy of the file on your hard drive would be instantly deleted, requiring the user to save the copy currently open in RAM or lose it forever.

Which is not how any OS that i've ever used works (Win or Linux), because that behavior would not make any sense. 

The idea that opening a file will result in the instantaneous deletion of that file makes no sense-- To me, anyway. 

if that were the behavior of geary, then if the computer crashed or the mail client crashed before saving, the draft would be lost. 

As a programmer, i would never delete a file opened for editing-- i would allow the user to either discard their changes, or overwrite the file on disk with the changed file. 

is the behavior you described the intention of the geary design team? 

thx!

Yeah, I was obviously confused.  The goal of the draft manager is to have one draft (not none) saved on the server at all times.  The current draft will not be deleted until the next one is saved.  However, we automatically save a new draft whenever there is a pause in composition.  Thus, the usual options when closing a composer are (1) save the current text as the draft, (2) keep the currently saved draft, which is (nearly) the same as the current text, and (3) delete the current draft.  I see no reason why (2) would be desired, especially since the user probably doesn't know the difference between the current text and the current draft, so we don't offer it as an option.

Note that there is no "Revert the changes made during this session" option here, though failures of the draft manager mean that sometimes an older draft will stick around.  If you actually want to track different versions of a draft, you want a version control system, not IMAP, which is spectacularly unsuited for this job.

We might consider offering a "Save current draft and close" option to this dialog.  Initially, this dialog did offer more choices, but it was deemed to be too confusing.  But draft support has improved since then, so it may be worth revisiting.  On the other hand, the long term goal is to get rid of this dialog in most cases (bug #730486), so it may not be worth polishing it up.

When you close a draft, either new or a previously saved one, the dialog is the same ("Do you want to discard this message?") and offers 3 action buttons:

* Keep will save the draft in its current state
* Discard will *delete the draft*
* Cancel will keep the draft open so you can edit it again

I'm a bit confused by the report.
The reporter wrote that in the past there were only 2 options available:

- Cancel canceled the closing of window. This is ok.
- Discard discarded the latest changes but kept the old draft saved. Is it really true? Robert's reply seems to reject this, when he says that "if you want to track different versions of a draft, you want a version control system, not IMAP. I totally agree.

At any rate, there's no confusion about which button will save the draft and which one will delete it. So I'll close this as WONTFIX.
Feel free to reopen it if I missed something.

"Keep will save the draft in its current state"

But what IS its "current" state? State when last saved? Or state in the editor? STILL CONFUSING. 


I'm NOT suggesting a version control system. I'm requesting a temporary backup during editing session. 

My preference and past experience as user, is that the draft on disk will NOT get overwritten during editing session, until I manually save during editing, OR click "save changes" button when queried by the program at the end of the editing session. 

"we automatically save a new draft whenever there is a pause in composition."

Save WHERE? The copy on disk should NEVER be overwritten until the user explicitly specifies in the 2 ways I mentioned above. 

Your automatic save feature should NOT overwrite the draft on disk. It should save to a temporary, hidden location. Could be in same Drafts folder in a HIDDEN state. Or, could be in a local hidden temp folder. Doesn't matter. 

On closing the editing session, that hidden draft will always get deleted. 

If program or computer crashes during editing session, then on reboot Geary will discover the hidden draft, and Geary will know the editing session crashed. Then Geary can give user option to activate editing session on that backup. But a recovery feature is NOT the topic or purpose of this report.

Explained in comments.

Johny, we appreciate your input, but please refrain from shouting. You have a good argument here, but you won't convince anyone of it if you're not treating them respectfully.

Federico suggested reopening the bug if he mis-understood, so there's no reason to assume he was acting in bad faith.

I'm not shouting. I use caps because there's no underline, bold, or italics. 

I completely respect everyone.

I'm very grateful for everyone's work on Geary, and excited about continued development. I'm sure everyone is sincere. Thx!

"On closing the editing session, that hidden draft will always get deleted."

Temp hidden draft should also get deleted when editing session is saved At that moment, the temp backup is no longer needed, because there are no unsaved changes.

Closing this in favour of https://gitlab.gnome.org/GNOME/geary/issues/517