notmuch/test/test-lib.el, branch 0.31.3

emacs: Do not abuse advice to monkey patch while testing

2020-08-10T00:17:06Z

Use `cl-letf*' instead.

emacs: Drop old advices that were only need for Emacs 23

2020-08-10T00:16:12Z

Fix typos

2020-08-10T00:14:36Z

emacs: Various cosmetic changes

2020-08-10T00:14:36Z

emacs: Use 'when' instead of 'if' when there is no ELSE part

2020-08-09T23:52:34Z

emacs: Use 'unless' instead of 'when' and 'not'

2020-08-09T23:51:26Z

Also use 'unless' in a few cases where previously 'if' was used with 'not' but without an ELSE part.

test: Remove misguided emacs testing utilities

2020-07-28T11:39:58Z

The goal of this abstraction was to save space. But that failed as the result actually was that four trivial lines got replace with 15 fairly complicated lines. The opposite of what it was supposed to do. Also it made it harder to come up with the fix in the previous commit; simply grepping for the relevant symbols did not work because they get constructed at run-time instead of appearing in the source file.

test: Deal with Emacs 27 switching to lexical scope by default

2020-07-28T11:39:44Z

Starting with Emacs 27 undeclared variables in evaluated interactive code uses lexical scope. This includes code passed with '--eval' as we do in the Emacs tests, which also happen to assume dynamic scope. - This can affect variables defined by libraries that we use. We let-bind such variables to change the behavior of functions which we then call with these bindings in effect. If these libraries are not loaded beforehand, then the bindings are lexical and fail to have the effect we intended. At this time only 'smtpmail' has to be loaded explicitly (for the variables let-bound in emacs_deliver_message and emacs_fcc_message). 'message' doesn't have to be loaded explicitly, because loading 'notmuch' (in 'run_emacs') already takes care of that, indirectly. - Our own testing-only variables also have to be declared explicitly. We should have done that anyway, but because of how and where these variables are used it was very easy to overlook that (i.e. it isn't something the byte-compiler ever looks at). Not so in Emacs 27 anymore; here this oversight caused four tests to fail. The numeric values of these variables get incremented by functions that we add to hooks that are run by many tests, not just the tests where we actually inspect the value and therefore take care to let- bind the values to 0 before we begin. The global values therefore have to be numeric values as well. I have chosen -100 instead of 0 as the default in case someone writes a test that inspects the value but forgets to let-bind the value. I hope that the unusual negative value that one is going to see in such a case will help debugging the issue.

tests/smime: Use gpgsm instead of openssl for mml creation of S/MIME msgs

2020-04-30T20:54:37Z

The documentation for message mode clearly states that EasyPG (which uses GnuPG) is the default and recommended way to use S/MIME with mml-secure: [0] https://www.gnu.org/software/emacs/manual/html_node/message/Using-S_002fMIME.html To ensure that this mode works, we just need to import the secret key in question into gpgsm in addition to the public key. gpgsm should be able pick the right keys+certificates to use based on To/From headers, so we don't have to specify anything manually in the #secure mml tag. The import process from the OpenSSL-preferred form (cert+secretkey) is rather ugly, because gpgsm wants to see a PKCS#12 object when importing secret keys. Note that EasyPG generates the more modern Content-Type: application/pkcs7-signature instead of application/x-pkcs7-signature for the detached signature. We are also obliged to manually set gpgsm's include-certs setting to 1 because gpgsm defaults to send "everything but the root cert". In our weird test case, the certificate we're using is self-signed, so it *is* the root cert, which means that gpgsm doesn't include it by default. Setting it to 1 forces inclusion of the signer's cert, which satisfies openssl's smime subcommand. See https://dev.gnupg.org/T4878 for more details. Signed-off-by: Daniel Kahn Gillmor

emacs: Use `cl-lib' instead of deprecated `cl'

2020-04-27T10:36:10Z

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.