GNOME Bugzilla – Bug 258233
Viewing thread follow-up messages "concatenated" in one window
Last modified: 2020-10-29 17:17:09 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: This is a suggestion for reading threaded email messages. It would be realy nice to have a threaded message view that would parse an email thread to display a conversation in one window by tracking the new items in the conversation removing all the previous bits of the conversation. It would alleviate the need to go back and forth through emails makign sense of a conversation.
changing the subject to a more precise one.
seems like David Morrison is working on that stuff as part of google's "summer of code" project.
for your interest, check out <http://blogs.gnome.org/dmorr> for the development of this request.
see <http://cvs.gnome.org/viewcvs/evo-conversation/>
*** Bug 311454 has been marked as a duplicate of this bug. ***
correcting the status whiteboard namespace to keep consistency. sorry for the noise, my fault.
harish, could this be moved to /evolution/plugins and be included to "normal" evolution?
Bumping version to a stable release.
*** Bug 532189 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > for your interest, check out <http://blogs.gnome.org/dmorr> for the development > of this request. Is there any news on this? That blog seems to have been deleted.
From looking at archive.org, seems he got frustrated: http://web.archive.org/web/20070808133203/http://blogs.gnome.org/dmorr The code is still available though: http://svn.gnome.org/viewvc/evo-conversation/
What is status on this? This is something that would be very good in core. I'm a bit surprised so few are asking for it. Maybe there isn't a big demand. But I feel Evolution is getting very cluttered and hard to navigate now with my ever rising email volume. The plugin didn't seem like the solution: http://lists.ximian.com/pipermail/evolution-hackers/2005-August/006280.html
The status is that nothing is happening here.
(In reply to comment #11) > The code is still available though: That is http://git.gnome.org/browse/archive/evo-conversation/ nowadays.
*** Bug 727204 has been marked as a duplicate of this bug. ***
This would be a really awesome feature. Thunderbird is a great example where you can right click a message and select "Open Message in Conversation" and you get a window with all of the messages in that conversation. Not having this feature can be really painful when trying to look in the history of a long conversation that isn't necessarily in the same folder or view.
https://afaikblog.wordpress.com/2010/11/25/evolution-re-evolved/ Allan mockups are amazing, I would love to see them become true. These is also a bounty for this feature: https://www.bountysource.com/issues/36252667-viewing-thread-follow-up-messages-concatenated-in-one-window
It would be awesome to have a conversation view in Evolution. Any chance this will happen soon?
Would you fancy writing the code to make this happen? See https://wiki.gnome.org/Git/Developers for more information.
If I understand it properly, then one part of the issue is to get proper messages into the view. That would been to consider all messages from the current folder and from the Sent folder of the account the current folder belongs to, and pick from it all messages related to the selected message, right? That is doable, with a certain performance hit at the moment. One surely should not check all available folders in the account or any such thing. I'm only asking to confirm that the point of view of all interested parties is the same. I'm surely not going to work on this any time soon (this is a complex issue and requires some work to have it done efficiently, without significant performance hits).
I'm not sure you can do this properly without checking all folders in the account. For example I often do this in the Inbox, but many of the messages are in "All Mail". If you had an index of all messages by ID this should be quite quick to do. If you don't then it wouldn't be fast, even for large folders.
Right, All Mail is a special folder of Gmail, provided by the server. Evolution works with general accounts (not only Gmail servers, but any IMAP/POP3/NNTP/...), where most of them do not provide any such folder. Constructing it on demand is possible, but it has its downside, from memory consumption to performance. That's why I mentioned the compromise to search in current folder and configured Sent folder only, even it can get inaccurate in some cases. Index of all messages by ID is not enough, to construct threads you also need In-Reply-To and References headers (I'm not even thinking of thread-by-subject). There is no such index for all messages in the account, not talking that one message ID can be saved in multiple folders (imagine you send a reply to a mailing list; evolution assigns an ID to that message, then it saves it to your Sent folder and you receive "a copy" from the mailing list as well).
> All Mail is a special folder of Gmail Of course, my point was that just searching the current folder is not helpful in my case. I guess in the GMail case you could search *just* the All Mail folder but in the general case you should be able to search though all downloaded mail. This is what thunderbird does and it works really well. > That's why I mentioned the compromise to search in current folder and configured Sent folder only, even it can get inaccurate in some cases Personally I would prefer accuracy over performance. However you can also be smart and search the current folder and Sent first. Then proceed to do a full scan for the rest of the messages if you don't want to build an index. > Index of all messages by ID is not enough, to construct threads you also need In-Reply-To and References headers That's true, to go in reverse you need the references headers. That should still be a compact enough index to be useful. You could just make a table mapping message ID/reference to message. Then you just have to recursively lookup the messages. > I'm not even thinking of thread-by-subject I would recommend ignoring this case for now. It can be approximated with a search. > There is no such index for all messages in the account It might be worth adding this, although I suspect that for most people just searching in all downloaded folders wouldn't be too slow. > one message ID can be saved in multiple folders Of course, it isn't difficult to dedupe these though.
I would make it work on a single folder to begin with. That would already provide a useful basis. Then, as the next iteration, I would put into the preference panel a list of extra folders to look. - On Gmail accounts, it would be enough to use "[All Mail]" folder. - On regular accounts, depending on the way the user organizes the messages, it may be sufficient to use INBOX and Sent in addition of the current folder - And finally, there would be the slow, search-everywhere option
i opened a issue at https://gitlab.gnome.org/GNOME/evolution/issues/401 but as Andre saw this issue is the same. Any progress on this or a plug-in that can solve this?
Nope, no progress on this, I'm sorry.
There are two options at this point: The Geary app, this is a more limited mail client than Evolution though. The elementaryOS Mail client is a rewrite of Geary that uses the Evolution data server backend, so maybe it and Evolution could share the same accounts.
@Paul, I took a look to the Geary app and it joins the views differently but solves my issue. Due to the limited functionality it is not usable in my case. I use a lot GPG and calendar email which are currently in development (as I saw on gitlab). Will be tracking the project to see its evolution.
Just adding my 2 cents here. Personally, I would have prefer a gradual evolution of Evolution (sic!). Evolution is a very capable email client, with a lot of functionalities. It just need a modern UI, which can be done gradually. It will be a long time before Geary can really catch up with evolution in terms of features.
Superseded by https://gitlab.gnome.org/GNOME/evolution/-/issues/401
*** Bug 557391 has been marked as a duplicate of this bug. ***