thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.32 2021-01-15T10:47:48Z 2021-01-15T10:47:48Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:10Z urn:sha1:9b5fd49ab2af70e75284c8df6c3d9765b6f22a76 When called from code, then this function returns non-nil when the message at point is a matched message. However it does nothing at all to present that information to the user when it called interactively. It is therefore safe to conclude that nobody is using this as a command. 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:40:58Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:01:01Z urn:sha1:692acdf9da2ca93d46259ca31780ed632c2975c4 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. 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. 2021-01-13T10:56:40Z Jonas Bernoulli jonas@bernoul.li 2021-01-10T14:00:37Z urn:sha1:5b19e6e1b4dc0ef13b5662707e097a740f9dc8a2 Commonly `set' is only used if there is no way around it; i.e. when the variable cannot be known until runtime. 2020-12-06T20:23:38Z Jonas Bernoulli jonas@bernoul.li 2020-11-16T21:28:42Z urn:sha1:adfded9ed0a5a4b06886f462314cd4511cb72d47 One should never bind unnamed commands in keymaps because doing that makes it needlessly hard for users to change these bindings. Replace such anonymous bindings with named commands that are generated using macros and some boilerplate. Using macros is better than using a simple loop because that makes it possible for `find-function' to find the definitions. Eat your boilerplate--it forms character. Admittedly this approach is quite ugly and it might be better to teach the original commands to support different buffers directly instead of requiring wrapper commands to do just that. Never-the-less as a short-term solution this is better than what we had before. 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.