aboutsummaryrefslogtreecommitdiffstats
path: root/worker/notmuch/lib
Commit message (Collapse)AuthorAgeFilesLines
* messages: allow displaying email threadsy0ast2021-11-132-8/+127
| | | | | | | | | | | | | Display threads in the message list. For now, only supported by the notmuch backend and on IMAP when the server supports the THREAD extension. Setting threading-enable=true is global and will cause the message list to be empty with maildir:// accounts. Co-authored-by: Kevin Kuehler <keur@xcf.berkeley.edu> Co-authored-by: Reto Brunner <reto@labrat.space> Signed-off-by: Robin Jarry <robin@jarry.cc>
* notmuch: remove gc close hooksReto Brunner2020-12-021-0/+1
| | | | | | | We frequently had issues with notmuch segfaulting and my guess is that this was due to the garbage collection magic used in the module. This changes to a fork that ripped the functionality out.
* notmuch: close tag objectReto Brunner2020-09-241-0/+1
|
* notmuch: manually close notmuch objectsReto Brunner2020-08-071-0/+3
| | | | | There seems to be some race with the automatic closing that should happen in theory... close it manually where we can to avoid the issue
* notmuch: avoid stale DBsReto Brunner2020-02-161-99/+133
| | | | | | | | | | | | | | Opening a notmuch DB gives you a snapshot of the stage at that specific time. Prior to this, we only reopened the DB upon writing. However, if say a mail sync program like offlineimap is fetching new mail, we would never pick it up. This commit caches a db for a while, so that we don't generate too much overhead and does a reconnect cycle after that. I hardcoded a value as I don't think that having an option would be beneficial. Any write operation (meaning reading mail) anyhow flushes the DB by necessity. (we need to close to commit tag changes, which changing the read state is)
* notmuch: emit LabelList eventReto Brunner2019-12-211-0/+17
|
* notmuch: sync maildir flagsReto Brunner2019-09-161-1/+4
| | | | Syncs back special notmuch tag like unread to the underlying maildir store
* notmuch: extract all notmuch db operations.Reto Brunner2019-09-161-0/+179
For some reason the current code frequently segfaults due to an invalid C memory address. This commit mediates that by never keeping an object alive longer than absolutely necessary.