notmuch, branch debian/0.38_rc0-1thread-based email index, search, and tagginghttps://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.38_rc0-12023-08-24T13:56:33Zdebian: set suite to experimental2023-08-24T13:56:33ZDavid Bremnerdavid@tethera.net2023-08-24T13:56:33Zurn:sha1:8c8fda965f17e90046de51743c8d545653085697doc: update copyright date2023-08-24T11:03:46ZDavid Bremnerdavid@tethera.net2023-08-24T11:03:46Zurn:sha1:5ed121bed92601e5512258f5a5f7bf9dbb705fd8debian: changelog for 0.38~rc0-12023-08-24T11:00:55ZDavid Bremnerdavid@tethera.net2023-08-24T11:00:29Zurn:sha1:695f663f810ec1586aca8bfb09883c4d772d1b3bNEWS: start NEWS for 0.382023-08-24T10:58:51ZDavid Bremnerdavid@tethera.net2023-08-24T10:58:51Zurn:sha1:aa5674fce027d55850f49cedcc52005b1566cf6bversion: set up 0.38~rc02023-08-24T10:58:19ZDavid Bremnerdavid@tethera.net2023-08-24T10:58:19Zurn:sha1:2f874fb2cc65e3486a47238f039aa80b990f8150test/setup: ignore blank lines in generated config2023-08-21T22:30:54ZDavid Bremnerdavid@tethera.net2023-08-20T15:23:19Zurn:sha1:368e0f61d5498ceae180e8349e848a4904008b0b
The presense of the blank lines between sections depends on the
version of glib. Strip them before comparison.
CLI/config: simulate top level comments when creating config2023-08-21T22:30:54ZDavid Bremnerdavid@tethera.net2023-08-20T15:10:56Zurn:sha1:df45194d5ffc110d69811eecd50f744c2b8c3805
According to discussion on
https://gitlab.gnome.org/GNOME/glib/-/issues/3078
it looks like upstream will stop supporting top of file comments.
It is questionable whether we really need this feature, but for now
update notmuch-config to simulate it.
test/emacs: adapt to breaking change in Gnus defaults2023-08-20T17:32:02ZDavid Bremnerdavid@tethera.net2023-08-20T17:32:02Zurn:sha1:1719b9e568fb944ffb91126b164a18a30a415d0a
As of Emacs 29.1, In-Reply-To is in the default value for
message-hidden-headers. We actually want to see that in the test
suite, so remove it again. To future proof the tests, fix a default
value for message-hidden-headers specifically for the test suite.
lib/n_d_remove_message: do not remove unique filename2023-07-22T10:15:59ZDavid Bremnerdavid@tethera.net2023-07-20T12:08:01Zurn:sha1:b6f144abe1f5aa3519240cf52f4cb9907fefcd0e
It is wasteful to remove a filename term when the whole message
document is about to be removed from the database. Profiling with perf
shows this takes a significant portion of the time when cleaning up
removed files in the database.
The logic of n_d_remove_message becomes a bit more convoluted here in
order to make the change minimal.
It is possible that this function can be further optimized, since the
expansion of filename terms into filenames is probably not needed
here.
lib/message: check message type before deleting document2023-07-22T10:11:46ZDavid Bremnerdavid@tethera.net2023-07-20T12:08:00Zurn:sha1:d93d49b6aed5b3f71651ffe79225da08c7d8f1aa
It isn't really clear how this worked before. Traversing the terms of
a document after deleting it from the database seems likely to be
undefined behaviour at best