thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=master 2023-10-06T23:37:16Z 2023-10-06T23:37:16Z David Bremner david@tethera.net 2023-10-06T23:01:09Z urn:sha1:5de7beec160d488c61d8ee65034b53205442f128 The previous version essentially repeated the source code, and generated a compiler warning. 2021-09-11T13:16:47Z David Bremner david@tethera.net 2021-08-29T19:23:29Z urn:sha1:a890241138ea468f8a275941b02da39b4e894c1e Initially just set the working directory, to avoid (the implicit) call-process crashing when the default-directory points to a non-existent location. Use of a macro here is over-engineering for this change, but the same change needs to be applied to several other process creation primitives. 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-01-15T10:49:07Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:12Z urn:sha1:a2bf29ad359539ed48a75ebb593897382d9a1de4 Users may type some text into the buffer on an address line, before actually invoking address completion. We now use that text as the initial input when we begin address completion. Previously we did knowingly replace the actual initial input with some completion candidate that happens to match. Which candidate is used is essentially random, at least when the actual initial input is short. As a result users very often had to begin completion by deleting the less than helpful "initial input". 2021-01-15T10:48:24Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:11Z urn:sha1:055294454fb944a2aec062fbb974665b02d9eaeb IMO Notmuch should not override the default completion mechanism by default, at least not globally. But since users are already used to this behavior it is probably too late to change it. Do the next best thing and at least allow users to opt out. 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:38:43Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:00Z urn:sha1:65fc5ea758b959ceec173b90e57cbca22f57c4a2 2021-01-15T10:38:00Z Jonas Bernoulli jonas@bernoul.li 2021-01-13T17:37:50Z urn:sha1:16b2db0986ce0ed7c420a69d0a98bb41e9ca4bd8 2021-01-13T11:16:23Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:48Z urn:sha1:0067a43ea2ee554eafed1e1300a71259cd6b6a6d The previous commit switched to lexical-binding but without dealing with the new warnings about unused lexical arguments and variables. This commit deals with most of them, in most cases by either removing leftover bindings that are actually unnecessary, or by marking certain arguments as "known to be unused" by prefixing their names with "_". In the case of the functions named `notmuch-show-insert-...' the amount of silencing that is required is a bit extreme and we might want to investigate if there is a better way. In the case of `notmuch-mua-mail', ignoring CONTINUE means that we do not fully follow the intended behavior described in `compose-mail's doc-string.