+1
This could be quite nice for following along on a long mailing list discussion.
https://github.com/emersion/go-imap-sortthread now has support for threading so this could make some progress.
I'm not entirely sure how the design for threading inside the client would work, config option / command / something else?
A config option, you'll want to be able to set that to the default upon startup.
Commands aren't good for that
I could see some use in being able to flip between date-sorted and thread-sorted. For example you just want to see the latest messages and then use a command to see the previous messages in the thread. That's sort of like how gmail works.
I certainly would not object to just having a config option as a first pass.
You can always flip config options at runtime
set .
... thanks sr.ht for stripping html that isn't even HTML for God's sake!
set category.option value
Just FYI, I have been working on this. Please ping me on IRC if you want to chat about it.
I'd also be very interested in a threaded view. However, I don't think assembling threads should be done client-side.
IMAP seems to support threading, and backends like notmuch are also probably much faster when loading threads or displaying query results in threaded view.
what gave you the notion that this will be implemented client side?
The patches sent by keur do use the workers ability to efficiently get the threads iirc
You're right - found https://lists.sr.ht/~sircmpwn/aerc/patches/8864 now aswell, it indeed uses the workers for threading. I'll give it a try, and will also take a look at adding notmuch support :-)
You will still need some form of client side threading because not all IMAP servers support the extension. Notably Gmail has a nonstandard threading extension. Implementing REFERENCES client side and falling back on it if the thread extension is not supported ensures we support all servers. This is what mutt does (it doesn’t even utilize the extensions).
In v2 made the mistake of trying to do both server and client side threading in the same patch set. Instead I should’ve just cleaned up server side threading, got that reviewed and merged, then implemented client side threading.
On Feb 1, 2020, at 3:33 PM, ~flokli outgoing@sr.ht wrote:
I'd also be very interested in a threaded view. However, I don't think assembling threads should be done client-side.
IMAP seems to support threading, and backends like notmuch are also probably much faster when loading threads or displaying query results in threaded view.
-- View on the web: https://todo.sr.ht/~sircmpwn/aerc2/94#comment-5980
Hi, I'm just curious if there has there been any movement on this?
Yes. y0ast has a patch that enables this for imap (when supported by the server) and notmuch.
https://lists.sr.ht/~sircmpwn/aerc/patches/21895
It needs some work in order to get it merged, and I don't think anyone has taken it over yet.
Could we get this enabled for mbox/maildir first if IMAP server compatibility is the issue? That would allow using OfflineIMAP or fetchmail or mbsync in combination with aerc, similar to how mutt/alpine/emacs is often used.
I am now offering a bounty for completion of this feature. Include a Monero address in the message for the commit resolving this issue and I will send 1.0 XMR to it. This is roughly $280 US as of today's exchange rates.
[dupe message]
Partially fixed by commit https://git.sr.ht/~rjarry/aerc/commit/dc2a2c2dfd6dc327fe40fbf2da922ef6c3d520be
I am closing this issue for now, maybe we can refine the feature someday.
Why isn't it in the main repo? (What's the role of ~rjary/aerc for the project?)
Hi,
Drew does not want to get involved in the project anymore. I have created a fork.
See this thread for more details:
https://lists.sr.ht/~sircmpwn/aerc/%3CCFBVJ3G1Y4YB.ZI6C02D0MS0S%40diabtop%3E