TRACKING: Develop drafts feature

[neiljp]

This could be comparable to the webapp, but has various aspects in which development could proceed.

A) Per narrow: a first version could just maintain the last message draft, and then develop to one per narrow
B) Multiple drafts: a first version could have one draft, and potentially to multiple drafts

It would be worth reviewing the way the webapp handles this, and there have been discussions on the existing UI and potential changes on chat.zulip.org in the #design stream.

[sumanthvrao]

We might want to take this up after zulip/zulip#3775 is implemented and an API call is available for the same.

[neiljp]

A simple drafts feature was added in #772 which allows manual saving and restoring of the state during a session, supporting moving between narrows mid-compose.

[neiljp]

The drafts UI in the webapp is under discussion, and there is not yet a server-side drafts feature.

For now it would be useful to move beyond the existing draft(s) feature (1/session, not persisted).
Elements to consider:

• persistent draft(s) (currently the one draft is lost if a session ends intentionally - or otherwise, such as a rare crash)
• keep current explicit draft saving behavior, or automatically save drafts? This may work best with...
• multiple drafts (needing a pop-up for selection, and logic for deletion/removal/auto-pruning?)
• locations to persist drafts (there's not dedicated zulip[-terminal] file location, so Improve zuliprc location/specifying (eg. dot-file or .config/) #678 may be a sensible precursor to all this work)

edit The last point may not be quite true, depending on which location we persist to, and could be handled in tandem in any case.

[neiljp]

A brief note to make it clear that the currently useful work in eg. #1442 / #1342 can be adjusted later upon implicit-/auto-save of multiple drafts, as discussed in the topic associated with that PR/issue.