GNOME Bugzilla – Bug 738188
Allow select-replies from multiple messages
Last modified: 2015-01-14 23:18:56 UTC
With bug #712912, we allow select-replies. Multiple selections can be used to quote different parts of a message. But replies are tied to a particular message in the mailbox -- you cannot select parts of different messages to get them all in the same reply. This would be very handy for mailing lists. The basic implementation won't be difficult, but there are some details in the behavior we need to figure out: 1) What IDs show up in the "References" and "In-Reply-To" headers? References can get the IDs of all messages replied to, but I think In-Reply-To can only take one. Should it be the first replied to, the last replied to, the earliest chronologically, or the latest chronologically? The last option makes the most sense to me, but we'd have to either save the info we need or recalculate that each time. 2) Who shows up in the "To:" and "CC:" entries? When we first reply to a new message, we can set the entries to the union of the current values and those for that message. But what happens when you try to change from reply to reply all, or vice versa? Should that affect all addresses, or just those from the most recently replied-to message? 3) Where should the composer appear in the conversation? Should it move to after the most recently referenced message, or does it stay in place? Should it move the to bottom of the conversation once the second message is referenced? Should it start down there?
See also bug #714606
1. In-Reply-To and References can both hold multiple Message-IDs. RFC 5322 has this to say (as though anticipating this feature): ** The "In-Reply-To:" field will contain the contents of the "Message-ID:" field of the message to which this one is a reply (the "parent message"). If there is more than one parent message, then the "In-Reply-To:" field will contain the contents of all of the parents' "Message-ID:" fields. Alas, I overlooked this when implementing the engine. Geary's current code doesn't handle this case and only allows for one In-Reply-To Message-ID. Something worth fixing whether or not we implement this feature (be liberal in what you receive and conservative in what you send). 2. I'd have to think more about that one. Does it make sense if you start doing multiple replies the composer is "locked" into that mode and always unions the recipients? 3. I don't think the composer should move around, that sounds bad. I think, like my prior comment, when you go down this route the composer is "locked" into place.
I just now pushed (commit 15cac88) support for multiple Message-IDs in In-Reply-To.
I realized that there's an even bigger problem lurking here: If I have multiple composers open and I hit reply, into which does the new quote go? Frankly, I don't know that there's a good answer to this. The right answer may be to allow only a single composer in the conversation viewer at a time. If we do this, does it still make sense to have the composer be embeddable at various places, or should we restrict it to being at the end? And if we stick it at the end, do we leave it in the WebView, or do we put it in a separate widget below the WebView. (After all, you might want to scroll up a ways, since now the message you're replying to may be far from the bottom.) This is all leading me to the conclusion that we'd get rid of the embedded composer. Before we go that far, a few other ideas. - We could require the user to drag the quote into the composer to quote it. Hitting reply would always open a new reply. But I have trouble believing that that is the desired behavior. - We could insert the reply into the most recently opened composer or the most recently focused composer. Either would behave correctly most of the time. Another wrinkle here is what to do about drafts once we open them in composers automatically.
At this point I'd say we should start looking at how other email clients with this feature operate. Does Gmail offer this feature? I believe Apple Mail does, although I don't know if it has an inline composer.
Branch at wip/738188-multireplies
Closed by 526f6e78 and preceding commits.