Re: [PATCH] python: add bindings for notmuch_message_get_property
Quoting Ruben Pollan (2017-11-15 23:29:54) > Message.get_property (prop) returns a string with the value of the property. I only implemented get_property as is the only one I need to add support for session keys in alot (https://github.com/meskio/alot/tree/session-key). From the point of view of the MUAs I don't see much interest in exporting all the other functions to modify properties. But I was not sure if adding them to have the whole set of message property functions in python. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Stashed session keys
Quoting Daniel Kahn Gillmor (2017-10-25 08:51:45) > Now that cleartext indexing is merged, let's add the ability to stash > session keys! Nice feature. I'm using it and it works fine. I notice some speed up, improving the painfulness of reading long encrypted threads in alot. And I like to don't be able to have around my old private keys. I implemented some support for it in alot (using the patch I just sent adding notmuch_message_get_property to the python binding): https://github.com/meskio/alot/tree/session-key Thanks for the work. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] python: add bindings for notmuch_message_get_property
Message.get_property (prop) returns a string with the value of the property. --- bindings/python/notmuch/message.py | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/bindings/python/notmuch/message.py b/bindings/python/notmuch/message.py index d5b98e4f..11263736 100644 --- a/bindings/python/notmuch/message.py +++ b/bindings/python/notmuch/message.py @@ -19,7 +19,7 @@ Copyright 2010 Sebastian Spaeth """ -from ctypes import c_char_p, c_long, c_uint, c_int +from ctypes import c_char_p, c_long, c_uint, c_int, POINTER, byref from datetime import date from .globals import ( nmlib, @@ -113,6 +113,11 @@ class Message(Python3StringMixIn): _maildir_flags_to_tags.argtypes = [NotmuchMessageP] _maildir_flags_to_tags.restype = c_int +"""notmuch_message_get_property""" +_get_property = nmlib.notmuch_message_get_property +_get_property.argtypes = [NotmuchMessageP, c_char_p, POINTER(c_char_p)] +_get_property.restype = c_int + #Constants: Flags that can be set/get with set_flag FLAG = Enum(['MATCH']) @@ -433,6 +438,26 @@ class Message(Python3StringMixIn): _freeze.argtypes = [NotmuchMessageP] _freeze.restype = c_uint +def get_property(self, prop): +""" Retrieve the value for a single property key + +:param prop: The name of the property to get. +:returns: String with the property value or None if there is no such + key. In the case of multiple values for the given key, the + first one is retrieved. +:raises: :exc:`NotInitializedError` if message has not been + initialized +""" +if not self._msg: +raise NotInitializedError() + +value = c_char_p("") +status = Message._get_property(self._msg, prop, byref(value)) +if status != 0: +raise NotmuchError(status) + +return value.value + def freeze(self): """Freezes the current state of 'message' within the database -- 2.15.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bounce/forward not working due to CR at line end
Kai Harries writes: > David Bremner writes: > >> During off-list discussion, Kai mentioned id:87a7zsm5ol@gmail.com as >> a message that he cannot bounce (and also not forward?). For me this >> forwards fine, but does not bounce because it has a corrupted Cc header, >> and my MTA rejects it. That doesn't sound related to the original >> problem report (nothing about line endings). > > Can you please evaluate the following on your system: > > (call-process "notmuch" nil t nil "show" "--format=raw" > "id:87a7zsm5ol@gmail.com") > > If I do this on my system, then the text that is inserted into the > buffer has ^M (CR) at the line endings. Is this expected? No ^M line endings for me. Can you check the file on disk? Maybe "od -a" lacking a better idea. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bounce/forward not working due to CR at line end
David Bremner writes: > During off-list discussion, Kai mentioned id:87a7zsm5ol@gmail.com as > a message that he cannot bounce (and also not forward?). For me this > forwards fine, but does not bounce because it has a corrupted Cc header, > and my MTA rejects it. That doesn't sound related to the original > problem report (nothing about line endings). Can you please evaluate the following on your system: (call-process "notmuch" nil t nil "show" "--format=raw" "id:87a7zsm5ol@gmail.com") If I do this on my system, then the text that is inserted into the buffer has ^M (CR) at the line endings. Is this expected? In contrast, if I evaluate the following: (require 'subr-x) (find-file (string-trim (shell-command-to-string "notmuch search --output=files id:87a7zsm5ol@gmail.com"))) then a buffer with the message is opened but with clean line endings (no ^M). > I guess we still need a good test case [1], but my best guess is that > something about Kai's settings. Kai, if you have the source unpacked > (even if not built), try > > $ ./devel/try-emacs-mua -Q > > and see if the problem is duplicated there. Yes, bounce is also not working in this mode. I only evaluated (setq message-send-mail-function (lambda () t)) (notmuch-hello) from the startup page (I have not loaded my ~/.emacs). But still the bounce fails with: Search failed: " " as message in the minibuffer. > [1]: I tried both the copy of that message I already have and the copy > Kai sent me, after changing it's message-id ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 11/18] cli/new, insert, reindex: update documentation for --try-decrypt=auto
> > -``--try-decrypt=(true|false)`` > +``--try-decrypt=(true|auto|false)`` I sympathize with Jamie's point about consistency here. I'm not sure if this was already mentioned, but the inconsistency between boolean and keyword arguments is a bit confusing also. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 03/18] crypto: use stashed session-key properties for decryption, if available
Daniel Kahn Gillmor writes: > I also >> don't know how motivated gmime upstream is to fix bugs in 2.6; I could >> certainly understand if the answer was "not very". > > I believe the answer is "not very" -- but if there are serious bugs (i > don't think we've talked about any of this stuff as bugs in gmime) then > we should probably try to raise them with him. I think Jani tried a bit to narrow it down, but didn't succeed. Part of the problem (which I suspect is endemic to crypto issues) is that we don't have public test cases. > >> There is, by the way, a function notmuch_built_with that can be used to >> introspect the library as to what optional features it is built >> with. It's used in notmuch_config to report back to the user about the >> presence of optional features. > > Is there any naming convention for these features? do you want me to > add a "session-key" label with a future revision of this branch? or are > you asking for something else? It could be a followup, but yeah, if there is some feature that is sometimes compiled in, and sometimes not, then it should be listed along with the others. For whatever reason, the existing convention is 'session_key' This discussion does make me think there should probably be a test in configure that sets a corresponding feature macro HAVE_GMIME_SESSION_KEYS, in a manner similar to HAVE_XAPIAN_COMPACT (possibly just centralizing the version comparison currently used). d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bounce/forward not working due to CR at line end
Kai Harries writes: > Hello, > > I am new to notmuch so excuse if the fault is on my end. For me > resending and forwarding of emails are not working if > message-forward-show-mml is enabled. The problems are CR at the line > endings. With the attached two patches I got it working for me. Maybe > someone more knowledgeable can see from it what the right solution would > be. During off-list discussion, Kai mentioned id:87a7zsm5ol@gmail.com as a message that he cannot bounce (and also not forward?). For me this forwards fine, but does not bounce because it has a corrupted Cc header, and my MTA rejects it. That doesn't sound related to the original problem report (nothing about line endings). I guess we still need a good test case [1], but my best guess is that something about Kai's settings. Kai, if you have the source unpacked (even if not built), try $ ./devel/try-emacs-mua -Q and see if the problem is duplicated there. [1]: I tried both the copy of that message I already have and the copy Kai sent me, after changing it's message-id ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch