thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.35 2021-09-11T14:11:29Z 2021-09-11T14:11:29Z David Bremner david@tethera.net 2021-09-11T14:04:08Z urn:sha1:e722b4f48c90ea6536ac7efef47f9d0f3d8cc191 Provide safe working directory 2021-09-11T13:27:38Z David Bremner david@tethera.net 2021-08-29T19:23:32Z urn:sha1:eb226437e1c0da6da86c04c78cbdd2020b982ad6 Provide a safe working directory. 2021-09-11T13:19:27Z David Bremner david@tethera.net 2021-08-29T19:23:30Z urn:sha1:5e5f2122f91413e93761ca4a3d30b0b8b0d5e38e As with notmuch--process-lines, initial purpose is to provide a safe binding for default-directory. This is enough to make notmuch-hello robust against non-existent or corrupt values default-directory, but probably not other views. 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-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.