accented characters

[Bruno Deremble]

Hi,
I am still new to notmuch and keep experimenting it; a lot of very
interesting features.
I realized that searching "été" and "ete" do not give the same answer
which may be confusing in some situation (in case the sender has an
accented name and may or may not sign his email with his accented name)

A way to handle this could be to only index non accented words which
requires to add a filter before the indexing process. I looked at the code
and it seems that this should be handled by gmime? 
there are also libraries that are supposed to do that such as 'unac'.

Is it something that you have been exploring already?

thank you
bruno
 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Stashed session keys

[Daniel Kahn Gillmor]

On Sun 2017-11-12 11:51:11 +0800, Daniel Kahn Gillmor wrote:
> On Sat 2017-11-11 15:31:36 -0800, Jameson Graef Rollins wrote:
>> 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"

Sorry, this should be "AND not property:index.decryption=success"

   --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 07/18] crypto: new decryption policy "auto"

[Jameson Graef Rollins]

On Sun, Nov 12 2017, Daniel Kahn Gillmor  wrote:
> 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.

I guess I'm confusing how things were before, when the crypto_ctx was a
notmuch-defined thing that included the GMimeCryptoContext.

It seems like _notmuch_crypto_t could just hold the GMimeCryptoContext,
as it does for earlier versions of GMime, which would make things easier
to pass around.  But this discussion is tangent to this patch series.

jamie.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: some issues with emacs 25

[David Bremner]

Matthew Lear  writes:

> I'm of the opinion that this is probably some sort of set up /
> configuration issue specific to 25, but I'm quite surprised. I don't
> have many settings for handling html stuff:
>
> (setq mm-text-html-renderer 'shr)
> (setq shr-inhibit-images nil)
> (setq mime-view-text/html-previewer 'shr)
> (setq mm-inline-text-html-with-images t)
> (setq notmuch-multipart/alternative-discouraged '("text/plain"))
>
> Is this reproducible for anyone else with notmuch from git/master as of
> today?

According to emacs upstream, this problem (or at least my reduced test
case) is fixed in emacs 26.1

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29273

Can you confirm that?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Stashed session keys

[Jameson Graef Rollins]

On Sun, Nov 12 2017, Daniel Kahn Gillmor  wrote:
>> 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.

I don't think it's a blocker at all, but I do think the term
normalization should happen before the next release, since I think we
should change "try-decrypt" -> "decrypt", which would affect things
already in master.  But I very much hope this series will land before
the next release, in which case I think it's fine to wait to do the
normalization after this series lands.

jamie.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: hook for notmuch-show-reply?

[David Bremner]

Linus Arver  writes:

> 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.

this probably needs to be done (or at least set up) before the reply
composition buffer is generated, since access to tag data is not easy in
the composition 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 use message-templ for this

  http://pivot.cs.unb.ca/git?p=message-templ.git;a=summary

Unfortunately it's not very widely available in package repos (melpa and
friends). It is in debian testing/unstable as elpa-message-templ.

> 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

I don't remember the details, but I doubt it still applies / works at
this point. There have been many changes to the way reply works in
notmuch-emacs.

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch