thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.28 2017-12-29T20:45:55Z 2017-12-29T20:45:55Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-19T16:40:55Z urn:sha1:af8255fb7159652a7d4e1fe4f1398302e1746cce This brings the --decrypt argument to "notmuch reply" into line with the other --decrypt arguments (in "show", "new", "insert", and "reindex"). This patch is really just about bringing consistency to the user interface. We also use the recommended form in the emacs MUA when replying, and update test T350 to match. 2017-12-08T12:08:47Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:24:02Z urn:sha1:fccebbaeef1e4b6489425afb13f419543d53d285 Here's the configuration choice for people who want a cleartext index, but don't want stashed session keys. Interestingly, this "nostash" decryption policy is actually the same policy that should be used by "notmuch show" and "notmuch reply", since they never modify the index or database when they are invoked with --decrypt. We take advantage of this parallel to tune the behavior of those programs so that we're not requesting session keys from GnuPG during "show" and "reply" that we would then otherwise just throw away. 2017-12-08T12:08:46Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:54Z urn:sha1:6802b333eb356fdeafd97a4e4ed74999d055a852 If the user doesn't specify --decrypt= at all, but a stashed session key is known to notmuch, when replying to an encrypted message, notmuch should just go ahead and decrypt. The user can disable this at the command line with --decrypt=false, though it's not clear why they would ever want to do that. 2017-12-08T12:07:02Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T06:23:52Z urn:sha1:798aa789b5d117cf11697bc97dd982bd5a2c2ac8 Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean. 2017-10-13T01:11:25Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-10-10T05:49:02Z urn:sha1:88f2a72ef1dcfce149bbac776652ea04e564726d The notmuch_crypto_t struct isn't used externally, and we have no plans to explicitly export it. Prefix its name (and associated functions) with _ to make that intent clear. 2017-10-10T01:24:02Z Jani Nikula jani@nikula.org 2017-10-07T08:44:04Z urn:sha1:0f314c0c99befea599a68bea51d759b4133efef6 C99 stdbool turned 18 this year. There really is no reason to use our own, except in the library interface for backward compatibility. Convert the cli and test binaries to stdbool. 2017-10-05T01:00:42Z Jani Nikula jani@nikula.org 2017-10-01T20:53:11Z urn:sha1:4a6721970a42a9f86149fb5d395d1001fed2d305 Several changes at once, just to not have to change the same lines several times over: - Use designated initializers to initialize opt desc arrays. - Only initialize the needed fields. - Remove arg_id (short options) as unused. - Replace opt_type and output_var with several type safe output variables, where the output variable being non-NULL determines the type. Introduce checks to ensure only one is set. The downside is some waste of const space per argument; this could be saved by retaining opt_type and using a union, but that's still pretty verbose. - Fix some variables due to the type safety. Mostly a good thing, but leads to some enums being changed to ints. This is pedantically correct, but somewhat annoying. We could also cast, but that defeats the purpose a bit. - Terminate the opt desc arrays using {}. The output variable type safety and the ability to add new fields for just some output types or arguments are the big wins. For example, if we wanted to add a variable to set when the argument is present, we could do so for just the arguments that need it. Beauty is in the eye of the beholder, but I think this looks nice when defining the arguments, and reduces some of the verbosity we have there. 2017-08-17T00:56:58Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-07-14T13:05:06Z urn:sha1:23eed88e32551d9e0cb9a86eae0a562a049a58af This argument seems to be unused, and format_part_sprinter isn't required to meet any specific API so it seems cleaner and simpler to drop it. 2017-07-15T00:23:52Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-07-14T13:12:00Z urn:sha1:e142de643d3bb4354f70e1490a97b491d1116e95 gmime 3.0 no longer offers a means to set the path for gpg. Users can set $PATH anyway if they want to pick a differently-installed gpg (e.g. /usr/local/bin/gpg), so this isn't much of a reduction in functionality. The one main difference is for people who have tried to use "gpg2" to make use of gpg 2.1, but that isn't usefully co-installable anyway. 2017-07-15T00:23:52Z David Bremner david@tethera.net 2017-05-20T12:05:22Z urn:sha1:4ce7591610444a1c5ef6f56b57af8e180437fa62 In gmime 3.0 this function is "transfer none", so no deallocation is needed (or permitted)