thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.32 2021-01-15T11:30:33Z 2021-01-15T11:30:33Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T18:47:22Z urn:sha1:1f14dbfbd72d5c4aa04c4903155060f7c69c608f The output of "notmuch show --format=sexp --format-version=4" may contain `:content-type' entries with `nil' as the value, when it fails to detect the correct value. Account for that in a few places where we would otherwise risk a type error. Note that `string=' does not choke on `nil' because it uses the `symbol-name' when encountering a symbol. 2021-01-15T10:47:28Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:09Z urn:sha1:371f481d93073cad23f7ce8579a83a4db09147ef 2021-01-15T10:47:10Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:08Z urn:sha1:f3d6fa2e40c45c3dbaef768e36f1544248851ddb Like `cl-lib' and `pcase', which are already available in all libraries, `subr-x' also provided many useful functions that we would like to use. Making `subr-x' available in every library from the get-go means that we can use the functions it defines without having to double check every single time, whether the feature is already available in the current library. 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: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. 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. 2021-01-13T11:16:04Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:47Z urn:sha1:fc4cda07a9afbbb545dcc6cd835ca697f6ef2a1b Doing so causes many new compile warnings. Some of these warnings concern genuine changes in behavior that have to be addressed right away. Many other warnings are due to unused variables. Nothing has changed here, except that the byte-compiler can now detect these pre-existing and harmless issues. We delay addressing these issues so that we can focus on the important ones here. A third group of warnings concern arguments that are not actually used inside the function but which cannot be removed because the functions signature is dictated by some outside convention. Silencing these warning is also delayed until subsequent commits.