| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
Exposes the notmuch tags accordingly, stubs it for the maildir worker.
|
| | |
|
| |
|
|
|
|
|
|
| |
Right now notmuch panics if something goes wrong in the configure event.
This patch checks for that and returns an error instead, so that we can at least
get the UI up and running (and all the other accounts)
The experience will be completely degraded until another configure event occurs.
|
| |
|
|
|
| |
A segmentation fault occurs when using the notmuch backend and a `query-map`
file that contains blank lines or comments.
|
| | |
|
| | |
|
| |
|
|
| |
Syncs back special notmuch tag like unread to the underlying maildir store
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
Notmuch only allows a single write connection, all other clients trying to
modify the db block. Hence we should only open one when we actually need it.
Apparently we also need to refresh the RO DB connection upon modification,
else we get stale message tag results
|
|
|
This commit introduces the notmuch backend.
The backend is conditionally compiled in if the "notmuch" tag is provided.
Most of the message types are implemented, with the notable exceptions
of DeleteMessages as well as any copy / move / append type.
Reason being, that those aren't normally applicable in a notmuch based workflow.
Changes v2 --> v3, based on review comments
* Use account config for configuration
|
