emacs: use cached encoded copy for fcc This fixes the bug reported by dkg in [1]. The movement of the call to n-m-setup-message-for-saving is so the cleanup of Fcc headers happens in the encoded version (otherwise Fcc headers may be saved to disk). [1]: id:87k1zm225v.fsf@fifthhorseman.net
emacs: notmuch-fcc-header-setup: fix regression With [1: 16b2db09] we lost the (undocumented) option to use no Fcc header only for From addresses matching a regexp. This brings back that feature and documents it. 1: 2021-01-15 16b2db0986ce0ed7c420a69d0a98bb41e9ca4bd8 emacs: various cosmetic improvements
emacs: require seq for seq-some Although the function dates from 2015, the autoload is newer. In particular [1] it is not found in Emacs 25.3. [1]: id:874ke85tqx.fsf@cgc-instruments.com
emacs: improve how cl-lib and pcase are required 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.)
emacs: avoid unnecessary let-bindings 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)?
emacs: various doc-string improvements
emacs: various cosmetic improvements
emacs: deal with unused lexical arguments and variables 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.
emacs: use lexical-bindings in all libraries 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.
emacs: make headings outline-minor-mode compatible `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.
emacs: do not quote self-quoting t
emacs: always use elisp quoting style in doc-strings Emacs doc-strings use neither markdown nor lisp symbol quoting.
emacs: Remove notmuch-read-char-choice Just use `read-char-choice', which existed since Emacs 24.1.
emacs: Increase consistency of library headers
emacs: Use 'and' instead of 'when' when the return value matters Also do so for some 'if' forms that lack an ELSE part. Even go as far as using 'and' and 'not' instead of 'unless'.
emacs: Fix indentation
emacs: Remove excess empty lines Most people who write lots of lisp tend to only sparsely use empty "separator" lines within forms. In lisp they feel unnecessary and since most files stick to this convention we get a bit confused when there are extra empty lines. It feels like the s-expressions are falling into pieces. All of this is especially true between a function's doc-string and body because the doc-string is colored differently, which visually already separates it quite sufficiently from the code that follows.
emacs: Shorten long lines
emacs docstrings: consistent indentation, newlines, periods Fixed emacs docstrings to be consistent. No functional change. - removed some (accidental) indentation - removed some trailing newlines - added trailing periods where missing (some exclusions)
emacs: Use `cl-lib' instead of deprecated `cl' Starting with Emacs 27 the old `cl' implementation is finally considered obsolete. Previously its use was strongly discouraged at run-time but one was still allowed to use it at compile-time. For the most part the transition is very simple and boils down to adding the "cl-" prefix to some symbols. A few replacements do not follow that simple pattern; e.g. `first' is replaced with `car', even though the alias `cl-first' exists, because the latter is not idiomatic emacs-lisp. In a few cases we start using `pcase-let' or `pcase-lambda' instead of renaming e.g. `first' to `car'. That way we can remind the reader of the meaning of the various parts of the data that is being deconstructed. An obsolete `lexical-let' and a `lexical-let*' are replaced with their regular variants `let' and `let*' even though we do not at the same time enable `lexical-binding' for that file. That is the right thing to do because it does not actually make a difference in those cases whether lexical bindings are used or not, and because this should be enabled in a separate commit. We need to explicitly depend on the `cl-lib' package because Emacs 24.1 and 24.2 lack that library. When using these releases we end up using the backport from GNU Elpa. We need to explicitly require the `pcase' library because `pcase-dolist' was not autoloaded until Emacs 25.1.