notmuch/util, branch 0.36_rc1

config: ignore leading/trailing spaces in ';'-delimited lists

2021-12-04T16:16:12Z

In [1] Ciprian observed that it was easy for users to mistakenly introduce leading and trailing space to new.tags when editing a notmuch config file. This commit strips spaces on either side of the ';' delimiter when splitting. In principle it would be possible to support tags (or other config values) with leading or trailing spaces by processing '\s' escapes in the input string. Currently such processing is not done. [1]: id:CA+Tk8fzjPLaEd3vL1f9ebk_bF_RV8PDTLzDupraTkCLCpJAmCg@mail.gmail.com

cli: remove enum names from typedefs

2021-10-23T11:39:16Z

There are some enum typedefs with the enum name: typedef enum _name_t { ... } name_t; We don't need or use the enum names _name_t for anything, and not all of the enum typedefs have them. We have the typedefs specifically to use the typedef name. Use the anonymous enum in the typedefs: typedef enum { ... } name_t;

util/unicode: allow calling from C++

2021-09-05T00:07:19Z

The omission of the 'extern "C"' machinery seems like an oversight.

cli/show: produce "email" element in sigstatus

2021-06-26T16:07:47Z

When the certificate that signs a message is known to be valid, GMime is capable of reporting on the e-mail address embedded in the certificate. We pass this information along to the caller of "notmuch show", as often only the e-mail address of the certificate has actually been checked/verified. Furthermore, signature verification should probably at some point compare the e-mail address of the caller against the sender address of the message itself. Having to parse what gmime thinks is a "userid" to extract an e-mail address seems clunky and unnecessary if gmime already thinks it knows what the e-mail address is. See id:878s41ax6t.fsf@fifthhorseman.net for more motivation and discussion. Signed-off-by: Daniel Kahn Gillmor

compat: rename {,notmuch_}canonicalize_file_name

2021-04-24T11:07:00Z

When compat canonicalize_file_name was introduced, it was limited to C code only because it was used by C code only during that time. >From 5ec6fd4d, (lib/open: check for split configuration when creating database., 2021-02-16), lib/open.cc, which is C++, relies on the existent of canonicalize_file_name. However, we can't blindly enable canonicalize_file_name for C++ code, because different implementation has different additional signature for C++ and users can arbitrarily add -DHAVE_CANONICALIZE_FILE_NAME=0 to {C,CXX}FLAGS. Let's move our implementation into a util library. Helped-by: Tomi Ollila Signed-off-by: Đoàn Trần Công Danh

util: run uncrustify

2021-03-13T12:45:34Z

This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h in the util directory

util: add strsplit_len: simplified strtok with delimiter escaping

2021-02-06T23:06:49Z

This will be used to make iterators for configuration values.

emacs: Use makefile-gmake-mode in Makefile*s

2020-08-10T00:14:36Z

Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor).

crypto: handle PKCS#7 envelopedData in _notmuch_crypto_decrypt

2020-05-23T01:11:40Z

In the two places where _notmuch_crypto_decrypt handles multipart/encrypted messages (PGP/MIME), we should also handle PKCS#7 envelopedData (S/MIME). This is insufficient for fully handling S/MIME encrypted data because _notmuch_crypto_decrypt isn't yet actually invoked for envelopedData parts, but that will happen in the following changes. Signed-off-by: Daniel Kahn Gillmor

crypto: Make _notmuch_crypto_decrypt take a GMimeObject

2020-05-23T01:11:33Z

As we prepare to handle S/MIME-encrypted PKCS#7 EnvelopedData (which is not multipart), we don't want to be limited to passing only GMimeMultipartEncrypted MIME parts to _notmuch_crypto_decrypt. There is no functional change here, just a matter of adjusting how we pass arguments internally. Signed-off-by: Daniel Kahn Gillmor