thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=master 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: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-30T00:51:55Z Jonas Bernoulli jonas@bernoul.li 2021-07-19T11:31:09Z urn:sha1:dd8c167850f376e46a13b567a8215937f4759c46 The byte-compiler wasn't happy about those. 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:40:58Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:01Z urn:sha1:692acdf9da2ca93d46259ca31780ed632c2975c4 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. 2021-01-13T11:10:27Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:46Z urn:sha1:2ca941163da06aed564dab1990fb333fd7457ec2 `outline-minor-mode' treats comments that begin with three or more semicolons as headings. That makes it very convenient to navigate code and to show/hide parts of a file. Elips libraries typically have four top-level sections, e.g.: ;;; notmuch.el --- run notmuch within emacs... ;;; Commentary:... ;;; Code:... ;;; notmuch.el ends here In this package many libraries lack a "Commentary:" section, which is not optimal but okay for most libraries, except major entry points. Depending on how one chooses to look at it, the "... ends here" line is not really a heading that begins a section, because it should never have a "section" body (after all it marks eof). If the file is rather short, then I left "Code:" as the only section that contains code. Otherwise I split the file into multiple sibling sections. The "Code:" section continues to contain `require' and `declare-function' forms and other such "front matter". If and only if I have split the code into multiple sections anyway, then I also added an additional section named just "_" before the `provide' form and shortly before the "...end here" line. This section could also be called "Back matter", but I feel it would be distracting to be that explicit about it. (The IMO unnecessary but unfortunately still obligatory "... ends here" line is already distracting enough as far as I am concerned.) Before this commit some libraries already uses section headings, some of them consistently. When a library already had some headings, then this commit often sticks to that style, even at the cost inconsistent styling across all libraries. A very limited number of variable and function definitions have to be moved around because they would otherwise end up in sections they do not belong into. Sections, including but not limited to their heading, can and should be further improved in the future. 2020-12-06T20:23:11Z Jonas Bernoulli jonas@bernoul.li 2020-11-16T21:28:41Z urn:sha1:54492ddf235f81d4b3f1b3ffbdd2aeedd0279b92 2020-12-06T20:22:18Z Jonas Bernoulli jonas@bernoul.li 2020-11-16T21:28:38Z urn:sha1:9fadab4e63afcc2adf06eac964da8bc8e5c9cd47 It is available since Emacs 24.3 and we require at least Emacs 25.