thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.33 2021-08-22T14:05:13Z 2021-08-22T14:05:13Z David Bremner david@tethera.net 2021-08-22T00:00:11Z urn:sha1:731697d671749a13634a2a4b843ce62f2927f64f This is a bit of a cheat, since the format does not actually change. On the other hand it is fairly common to do something like this to shared libary SONAMEs when the ABI changes in some subtle way. It does rely on the format-version argument being early enough on the command line to generate a sensible error message. 2021-06-05T11:24:51Z Tomi Ollila tomi.ollila@iki.fi 2021-01-16T17:17:09Z urn:sha1:03366a3c5aa313de41bddd61dedc5b5c002e0469 - declare-function notmuch-unthreaded lacked file name - declare-function notmuch-search had differently named last arg - note: check-declare-directory did not complain about that - declare-function notmuch-search-show-thread without nil - some functions declared to be in different file than those existed ("notmuch" -> "notmuch-lib") - some related function/declare lines were (/are now) wider than 80-columns; added line breaks (and proper indentation) there 2021-06-04T23:05:31Z David Bremner david@tethera.net 2021-06-04T23:05:31Z urn:sha1:d7ddfa0d0ec62c10ecd60779ca1edd9b6973593b After some discussion [1], I decided it is better to make notmuch users who rely on this behaviour customize mail-user-agent. This is consistent with the behaviour of other emacs mail packages. [1]: id:87k0nuhfrk.fsf@toryanderson.com 2021-02-05T14:12:53Z David Edmondson dme@dme.org 2021-02-03T09:10:20Z urn:sha1:8b7c09c66bbae35c52150a5ee81b94a82b2b3054 When prompting for one or more tags to add or remove to/from one or more threads, ensure that the set of tags offered for completion contains no duplicates. Some completion packages (e.g. selectrum) will include every member of the offered list, resulting in the same tag being indicated as a possibility several times. 2021-01-15T10:47:28Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:09Z urn:sha1:371f481d93073cad23f7ce8579a83a4db09147ef 2021-01-15T10:46:38Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:07Z urn:sha1:9ca1f945d9f5030600dc14ffff10d4dad14db4ca We need to load `cl-lib' at run-time because we use more from it than just macros. Never-the-less many, but not all libraries required it only at compile-time, which we got away with because at least some libraries already required it at run-time as well. We use `cl-lib' and (currently to a lesser extend) `pcase' throughout the code-base, which means that we should require these features in most libraries. In the past we tried to only require these features in just the libraries that actually need them, without fully succeeding. We did not succeed in doing so because that means we would have to check every time that we use a function from these features whether they are already being required in the current library. An alternative would be to add the `require' forms at the top of every library but that is a bit annoying too. In order to make sure that these features are loaded when needed but also to keep the noise down we only require them in "notmuch-lib.el", which most other libraries require, and in most of the few libraries that do not do so, namely "notmuch-draft.el", "notmuch-message.el" and "notmuch-parser.el". ("coolj.el", "make-deps.el", various generated libraries, and "notmuch-compat.el" are left touched.) 2021-01-15T10:45:30Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:06Z urn:sha1:f47e3333b5478e43840e55710311aebdd441fc0e To some extend this is a personal preference, but the preference is strongly dependent on whether one is used to a language that makes it necessary to use variables like this. This makes it perfectly clear that we are first getting and then using a "foo": (use-foo (get-foo)) Sure this has to be read "inside out", but that's something one better gets used to quickly when dealing with lisp. I don't understand why one would want to write this instead: (let ((the-foo (get-foo))) (use-foo the-foo)) Both `get-foo' and `use-foo' are named in a way that make it very clear that we are dealing with a "foo". Storing the value in an additional variable `the-foo' does not make this any more clear. On the contrary I makes the reader wonder why the author choose to use a variable. Is the value used more than once? Is the value being retrieved in one context and then used in another (e.g. when the current buffer changes)? 2021-01-15T10:45:20Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:05Z urn:sha1:25a8873c68f9ef033d393efaf7f4c46a29f798f4 2021-01-15T10:45:09Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:04Z urn:sha1:c6ac1121d4af9ff1187ae2f5a361fb74ef9c281b No longer use the function `notmuch-search-get-query', which does nothing but return the value of that variable. That function was added in [1: f47eeac0] for use in `notmuch-read-query' along-side related `notmuch-show-get-query' and `notmuch-tree-get-query' but using it here makes little sense. 1: f47eeac0b0186c3559eb559c4f0bee0e1fac1961 emacs: set default in notmuch-read-query 2021-01-15T10:44:01Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:03Z urn:sha1:42d32713be9a23346de09b84983e1dd3b44b3400 Define these variables as automatically buffer-local, meaning that they always become buffer-local when set unless explicitly told otherwise using `setq-default' or when using the Custom interface. Previously they were declared, which keeps the byte-compiler quiet but is not actually the same as being defined. `notmuch-search-mode' then made them buffer-local in the current buffer and then set the local values. This works but is not kosher. The definitions of the three non-option variables have to be moved up a bit to enable the change in the next commit, which see.