hook for notmuch-show-reply?
Hello, I want to make the "notmuch-show-reply" function compose messages with different signature styles depending on some arbitrary logic of the email being replied to. E.g., if I am responding to a message tagged "+mailinglist", I want to append a signature like the one in this email. On the other hand, for emails not tagged as such, I want to change the signature style (and also set message-cite-reply-position to 'above). How would I go about this? I tried using "message-signature-setup-hook" and "also message-setup-hook" but these hooks are run before the response body (yanked text) is inserted into the buffer. I don't really want to use "message-send-hook" or "message-send-mail-hook" because these are run just before sending messages, and I really want to see the signature in the buffer before sending the message. I found an old email from this list back in 2010 [1] proposing a hook to notmuch-reply and it seems relevant, but I am not sure if that patch is still recommended. [1]: https://notmuchmail.org/pipermail/notmuch/2010/002399.html -- Best, Linus ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: what is the concept of archiving?
Jani Nikula writes:
> On Thu, Nov 9, 2017 at 11:56 AM, Linus Arver wrote:
>> Unfortunately, I cannot find enough information online about what any of
>> these functions do, or what the concept of "archiving" means. From
>> reading some of the sources in notmuch-tree.el I found out that
>> archiving a message results in "applying the tag changes in
>> `notmuch-archive-tags' to it" but I am not sure what this means.
>
> Archiving, by default, simply means removing the inbox tag, either
> from a single message or from all messages in a thread. You can use
> notmuch-archive-tags to configure the tag change actions if you like.
>
>> I found out that the key bindings are in that same file, which assigns
>> "a" to notmuch-tree-archive-message-then-next; when I press "a" in my
>> inbox view (all messages tagged "inbox"), it appears to just remove the
>> "inbox" tag. I have some questions:
>>
>> (1) What is the point of archiving (what problem does it solve)?
>
> Remove the messages from your inbox search. (At least I prefer to keep
> this distinct from removing the unread tag; I archive tons of messages
> without reading, and I have some messages with inbox tag that I've
> already read.)
>
>> (2) Do any other things happen to such archived messages, apart from the
>> tag being removed?
>
> No. Optionally, you can configure notmuch-archive-tags to remove more
> or other tags, or add tags.
>
>> (3) How do I un-archive these messages, if I press the "a" key by
>> accident?
>
> Find the message, hit "k k a". ("k" enters a submenu for doing
> customizable tagging operations quickly, "k k" does the reverse
> operation.)
>
> BR,
> Jani.
That was very helpful, thanks.
--
Best,
Linus
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 07/18] crypto: new decryption policy "auto"
On Sat 2017-11-11 15:14:03 -0800, Jameson Graef Rollins wrote:
> On Wed, Oct 25 2017, Daniel Kahn Gillmor wrote:
>> diff --git a/util/crypto.h b/util/crypto.h
>> index b23ca747..dc95b4ca 100644
>> --- a/util/crypto.h
>> +++ b/util/crypto.h
>> @@ -16,7 +16,8 @@ typedef struct _notmuch_crypto {
>> } _notmuch_crypto_t;
>>
>> GMimeObject *
>> -_notmuch_crypto_decrypt (notmuch_message_t *message,
>> +_notmuch_crypto_decrypt (notmuch_decryption_policy_t decrypt,
>> + notmuch_message_t *message,
>> GMimeCryptoContext* crypto_ctx,
>> GMimeMultipartEncrypted *part,
>> GMimeDecryptResult **decrypt_result,
>
> Why does _notmuch_crypt_decrypt need to have
> "notmuch_decryption_policy_t decrypt" as an input argument? Isn't
> notmuch_decryption_policy_t already an attribute of the crypto_ctx? Is
> there some situation where the policy would differ from what's specified
> in the crypto_ctx?
crypto_ctx here is just a GMimeCryptoContext, which doesn't know
anything about notmuch_decryption_policy_t. Maybe i'm misunderstanding
your question?
I'd be happy to streamline the interface to this internal function, but
given that it's not an exported API, i'm not as concerned about things
like future cleanliness -- the notmuch source contains all invocations
of the function anywhere, so if we find a nicer way to streamline it in
the future, we can do that cleanup across the codebase in a single
commit.
Thanks for the review!
--dkg
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Stashed session keys
On Sat 2017-11-11 15:31:36 -0800, Jameson Graef Rollins wrote: > I have reviewed and tested this series, and it seems solidly > implemented and very well motivated. I have been using it regularly > for a couple weeks now and have found no issues with it's usage, and > have noticed the considerable speed up when viewing encrypted threads > (as much as x8 for show on a thread of just 8 encrypted messages). I > fully support it's integration unconditionally. thanks for the review, the testing, and the reportback. I'm glad to hear that it's giving you the same sort of speedups that it gives me. > Daniel likes to think of this in terms of being able to "delete" > encrypted messages in the wild (via deletion of the original > encryption key) whereas I like to think of it in terms of preserving > access to received encrypted messages after key rotation. Both > benefits hold, though, obviously. yes, these are different ways of looking at the same key management strategy. > I think these policies cover all potential use cases that I can see. > However, there will need to be further work on the UX to make things > flow more smoothly. Agreed. The goal of this series is to provide the framework that can be used to build smoother UX, but it doesn't get all the way to providing the smoothest possible UX. Such is the nature of toolkit development. > I haven't decided what's the best way to do that yet, but something > like the following happening automatically at inbox view might do the > trick: > > notmuch reindex --try-decrypt=true (tag:inbox AND tag:encrypted) This seems like a reasonable way to ensure that your long-term, personal secret keys only get accessed when you are interactively working with your mail user agent. You might be able to target the reindex even more narrowly by adding something like "AND not property:index-decryption=success" > Finally, I think it would be worthwhile to resolve the disparity between > the usage of "decrypt" and "try-decrypt" in the CLI and config options. > I'm not sure why we're using different terms in different contexts, even > though the meanings are essentially the same. A follow-up patch series > changing "try-decrypt" -> "decrypt" would probably be in order. If this series lands, i'd be happy to supply such an term-normalizing series for subsequent consideration. If people feel that this term normalization is the main blocker to landing this series, i could try to rebase it with a different UI terms, but rebasing the series for this change feels like busy-work to me (and would be more effort than a simple normalization patch on top). i'd rather spend my limited notmuch hacking+reviewing time providing useful features. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Stashed session keys
On Wed, Oct 25 2017, Daniel Kahn Gillmor wrote: > Now that cleartext indexing is merged, let's add the ability to stash > session keys! I have reviewed and tested this series, and it seems solidly implemented and very well motivated. I have been using it regularly for a couple weeks now and have found no issues with it's usage, and have noticed the considerable speed up when viewing encrypted threads (as much as x8 for show on a thread of just 8 encrypted messages). I fully support it's integration unconditionally. It should be emphasized that this series is actually fairly critical for good support of message encryption. Without this series it's actually possible to completely lose access to encrypted mail if one were to rotate/replace their encryption key, which one might reasonably be expected to do. Without access to the original encryption key or the message session key, there is no way to access the contents of an encrypted message. If, however, the session key is stashed in the index, the original encryption key can be destroyed and the message can still be accessed. Daniel likes to think of this in terms of being able to "delete" encrypted messages in the wild (via deletion of the original encryption key) whereas I like to think of it in terms of preserving access to received encrypted messages after key rotation. Both benefits hold, though, obviously. >++---+--+-+--+ >|| false | auto | nostash | true | >++===+==+=+==+ >| Index cleartext using | | X |X| X | >| stashed session keys | | | | | >++---+--+-+--+ >| Index cleartext| | |X| X | >| using secret keys | | | | | >++---+--+-+--+ >| Stash session keys | | | | X | >++---+--+-+--+ >| Delete stashed session | X | | | | >| keys on reindex| | | | | >++---+--+-+--+ I think these policies cover all potential use cases that I can see. However, there will need to be further work on the UX to make things flow more smoothly. I've been using this series with index.try_decrypt set to 'true', which causes encrypted messages to be indexed on new. I do this because I don't want to be bothered to manually initiate indexing of encrypted messages. However, since my mail retrieval and indexing happen in the background, this has the unfortunate side effect that I am occasionally presented with a gpg agent prompt at random unexpected times. Ideally, one would leave index.try_decrypt set to 'auto', and there would be an easy/automatic way to prompt reindexing when the user is interacting directly with their MUA. I haven't decided what's the best way to do that yet, but something like the following happening automatically at inbox view might do the trick: notmuch reindex --try-decrypt=true (tag:inbox AND tag:encrypted) Finally, I think it would be worthwhile to resolve the disparity between the usage of "decrypt" and "try-decrypt" in the CLI and config options. I'm not sure why we're using different terms in different contexts, even though the meanings are essentially the same. A follow-up patch series changing "try-decrypt" -> "decrypt" would probably be in order. But these are next steps. The series in question here is absolutely ready, and needed, as is. jamie. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 07/18] crypto: new decryption policy "auto"
On Wed, Oct 25 2017, Daniel Kahn Gillmor wrote:
> diff --git a/util/crypto.h b/util/crypto.h
> index b23ca747..dc95b4ca 100644
> --- a/util/crypto.h
> +++ b/util/crypto.h
> @@ -16,7 +16,8 @@ typedef struct _notmuch_crypto {
> } _notmuch_crypto_t;
>
> GMimeObject *
> -_notmuch_crypto_decrypt (notmuch_message_t *message,
> +_notmuch_crypto_decrypt (notmuch_decryption_policy_t decrypt,
> + notmuch_message_t *message,
>GMimeCryptoContext* crypto_ctx,
>GMimeMultipartEncrypted *part,
>GMimeDecryptResult **decrypt_result,
Why does _notmuch_crypt_decrypt need to have
"notmuch_decryption_policy_t decrypt" as an input argument? Isn't
notmuch_decryption_policy_t already an attribute of the crypto_ctx? Is
there some situation where the policy would differ from what's specified
in the crypto_ctx?
jamie.
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] doc: unify definition list usage across man pages
Make all parameter descriptions etc. use reStructuredText definition lists with uniform style and indentation. Remove redundant indentation from around the lists. Remove blank lines between term lines and definition blocks. Use four spaces for indentation. This is almost completely whitespace and paragraph reflow changes. --- doc/man1/notmuch-address.rst| 160 - doc/man1/notmuch-compact.rst| 16 +-- doc/man1/notmuch-config.rst | 256 +++- doc/man1/notmuch-count.rst | 65 +- doc/man1/notmuch-dump.rst | 116 +- doc/man1/notmuch-emacs-mua.rst | 64 +- doc/man1/notmuch-insert.rst | 64 +- doc/man1/notmuch-new.rst| 33 +++--- doc/man1/notmuch-reindex.rst| 21 ++-- doc/man1/notmuch-reply.rst | 94 --- doc/man1/notmuch-restore.rst| 118 +- doc/man1/notmuch-search.rst | 220 +- doc/man1/notmuch-show.rst | 256 doc/man1/notmuch-tag.rst| 33 +++--- doc/man1/notmuch.rst| 33 +++--- doc/man5/notmuch-hooks.rst | 55 + doc/man7/notmuch-properties.rst | 1 - 17 files changed, 779 insertions(+), 826 deletions(-) diff --git a/doc/man1/notmuch-address.rst b/doc/man1/notmuch-address.rst index dbac20f7b012..00cb554523e7 100644 --- a/doc/man1/notmuch-address.rst +++ b/doc/man1/notmuch-address.rst @@ -18,88 +18,84 @@ See **notmuch-search-terms(7)** for details of the supported syntax for Supported options for **address** include -``--format=``\ (**json**\ \|\ **sexp**\ \|\ **text**\ \|\ **text0**) -Presents the results in either JSON, S-Expressions, newline -character separated plain-text (default), or null character -separated plain-text (compatible with **xargs(1)** -0 option -where available). - -``--format-version=N`` -Use the specified structured output format version. This is -intended for programs that invoke **notmuch(1)** internally. If -omitted, the latest supported version will be used. - -``--output=(sender|recipients|count)`` - -Controls which information appears in the output. This option -can be given multiple times to combine different outputs. -When neither --output=sender nor --output=recipients is -given, --output=sender is implied. - -**sender** -Output all addresses from the *From* header. - -Note: Searching for **sender** should be much faster than -searching for **recipients**, because sender addresses are -cached directly in the database whereas other addresses -need to be fetched from message files. - -**recipients** -Output all addresses from the *To*, *Cc* and *Bcc* -headers. - -**count** -Print the count of how many times was the address -encountered during search. - -Note: With this option, addresses are printed only after -the whole search is finished. This may take long time. - -``--deduplicate=(no|mailbox|address)`` - -Control the deduplication of results. - -**no** -Output all occurrences of addresses in the matching -messages. This is not applicable with --output=count. - -**mailbox** -Deduplicate addresses based on the full, case sensitive -name and email address, or mailbox. This is effectively -the same as piping the --deduplicate=no output to **sort | -uniq**, except for the order of results. This is the -default. - -**address** -Deduplicate addresses based on the case insensitive -address part of the mailbox. Of all the variants (with -different name or case), print the one occurring most -frequently among the matching messages. If --output=count -is specified, include all variants in the count. - -``--sort=``\ (**newest-first**\ \|\ **oldest-first**) -This option can be used to present results in either -chronological order (**oldest-first**) or reverse chronological -order (**newest-first**). - -By default, results will be displayed in reverse chronological -order, (that is, the newest results will be displayed first). - -However, if either --output=count or --deduplicate=address is -specified, this option is ignored and the order of the results -is unspecified. - -``--exclude=(true|false)`` -A message is called "excluded" if it matches at least one tag in -search.tag\_exclude that does not appear explicitly in the -search terms. This option specifies whether to omit excluded -messages in the search process. - -The default value, **true**, pr
[PATCH] test: expand argument parsing sanity checks
Test the boolean --arg=true and --arg=false formats. --- Extracted from id:20171014131608.17587-1-j...@nikula.org as this makes sense independent of that series. --- test/T410-argument-parsing.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/test/T410-argument-parsing.sh b/test/T410-argument-parsing.sh index 71ed7e38553b..910843d684c6 100755 --- a/test/T410-argument-parsing.sh +++ b/test/T410-argument-parsing.sh @@ -37,4 +37,18 @@ positional arg 1 false EOF test_expect_equal_file EXPECTED OUTPUT +test_begin_subtest "--boolean=true" +$TEST_DIRECTORY/arg-test --boolean=true > OUTPUT +cat < EXPECTED +boolean 1 +EOF +test_expect_equal_file EXPECTED OUTPUT + +test_begin_subtest "--boolean=false" +$TEST_DIRECTORY/arg-test --boolean=false > OUTPUT +cat < EXPECTED +boolean 0 +EOF +test_expect_equal_file EXPECTED OUTPUT + test_done -- 2.11.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
