Re: [PATCH 0/3] python/notmuch2: a few docstrings and collect_tags()

2021-01-11 Thread Floris Bruynooghe
On Thu 07 Jan 2021 at 17:09 +, Michael J. Gruber wrote:
> As for the series: the notmuch based MUA "alot" switched to the new
> python bindings recently. collect_tags() is something I used in a
> feature PR submitted but not merged yet there (while on the old bindings),
> and in my updated feature PR there I directly roll
> notmuch2._tags.ImmutableTagSet(msgs, '_iter_p', 
> notmuch2.capi.lib.notmuch_messages_collect_tags).

You could do this entirely in the public bindings too could you not?
Something like (untested):

def collect_tags(db, query):
tags = set()
for msg in db.messages(query):
tags.update(msg.tags)

anyway, i guess the internal APIs you use won't change before your
patchset here lands so this doesn't matter much.


> I don't know whether this will land in alot, but feature parity of the
> new bindings with the old ones is a good aim

Thanks for contributing this!  I never aimed for full parity because I
didn't feel like making the API decisions for APIs I had no need to use
myself.  But it's great when people needing things can add it!


Cheers,
Floris
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 3/3] python/notmuch2: provide binding for collect_tags()

2021-01-11 Thread Floris Bruynooghe
Hi Micahel,

Thanks for adding this feature!

On Wed 06 Jan 2021 at 10:08 +0100, Michael J. Gruber wrote:
> diff --git a/bindings/python-cffi/notmuch2/_query.py 
> b/bindings/python-cffi/notmuch2/_query.py
> index 1db6ec96..a1310944 100644
> --- a/bindings/python-cffi/notmuch2/_query.py
> +++ b/bindings/python-cffi/notmuch2/_query.py
> @@ -2,6 +2,7 @@ from notmuch2 import _base as base
>  from notmuch2 import _capi as capi
>  from notmuch2 import _errors as errors
>  from notmuch2 import _message as message
> +from notmuch2 import _tags as tags
>  from notmuch2 import _thread as thread
>  
>  
> @@ -66,6 +67,17 @@ class Query(base.NotmuchObject):
>  raise errors.NotmuchError(ret)
>  return count_p[0]
>  
> +def collect_tags(self):
> +"""Return the tags of messages matching this query."""
> +msgs_pp = capi.ffi.new('notmuch_messages_t**')
> +ret = capi.lib.notmuch_query_search_messages(self._query_p, msgs_pp)
> +if ret != capi.lib.NOTMUCH_STATUS_SUCCESS:
> +raise errors.NotmuchError(ret)
> +self._msgs_p = msgs_pp[0]
> +tagset = tags.ImmutableTagSet(
> +self, '_msgs_p', capi.lib.notmuch_messages_collect_tags)
> +return tags.ImmutableTagSet._from_iterable(tagset)
> +
>  def threads(self):
>  """Return an iterator over all the threads found by the query."""
>  threads_pp = capi.ffi.new('notmuch_threads_t **')

How this this look on the C level for the memory allocator?  If the
query gets freed the messages also get freed?  In that case indeed the
messages do need to be kept alive together with the query indeed.
Keeping them as an attribute on the query object seems reasonable I
think, they'd be freed at the same time and I don't think this creates a
circular reference.

There's only a small detail though: to get the correct ObjectDestroyed
exceptions you need Query._msgs_p to be a _base.MemoryPoiniter
descriptor, like Query._query_p is currently.  And then you also need to
set it to None in Query._destroy.

It would also be really good to add at least one happy-path test for
this, ensuring that you get the tags in the query.  You could add some
to TestQuery in test_database.py.  The database is created with unread
and inbox tags i think (see conftest.py:75) so the messages should
already have some tags which is sufficient as you're not testing
notmuch's behaviour itself but only that the bindings give you a right
looking tagset (the tagset itself also has tests already, so no need to
test this extensively, just see if you have some tags).

Otherwise LGTM!

Cheers,
Floris
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 0/4] emacs: avoid type errors due to nil as content-type

2021-01-11 Thread Tomi Ollila
On Sun, Jan 10 2021, Jonas Bernoulli wrote:

> The fourth commit tries to address the issue raised in
> id:87k0sxa6c3@fifthhorseman.net.
>
>   The output of "notmuch show --format=sexp --format-version=4"
>   may contain `:content-type' entries with `nil' as the value,
>   when it fails to detect the correct value.  Account for that
>   in a few places where we would otherwise risk a type error.
>
> The other three commits cleanup the code I had to look at to do
> the above, because I just can't help myself.
>
> This does not apply without first applying
> id:20201214162401.19569-1-jo...@bernoul.li.

Perhaps this series still applies on top of that series from 2020-12-14,
but perhaps one should apply it on top of series (from 2021-01-10):

id:20210110140112.25930-2-jo...@bernoul.li

Meaning emails in range

id:20210110140112.25930-2-jo...@bernoul.li 
... 
id:20210110140112.25930-37-jo...@bernoul.li

(also visible in https://nmbug.notmuchmail.org/status/)

Note that messages 

20210110140112.25930-11-jo...@bernoul.li and
20210110140112.25930-12-jo...@bernoul.li

have base64 -encoded content, with CRLF line endings
so those don't apply as is, but CR's from the encoded
content must be deleted.

I used a hack to do so, appended to the end of this
email; David has done something that is more robust,
and perhaps from that we could get a tool to be added
in devel/ which could do this in the future.

Both of these series applied cleanly, and I will
start using those in my emacs mua.

I like these changes and hope these can be applied soon.

>
>  Jonas

Tomi

Usage: ./rmcr-base64.pl < input.mbox > output.mbox

--8<8<8<8<8<8<8<8<--

#!/usr/bin/perl
# -*- mode: cperl; cperl-indent-level: 4 -*-

use 5.8.1;
use strict;
use warnings;
use MIME::Base64;

while () {
print $_;
if (/^Content-Transfer-Encoding: base64/) {
while () { print $_; last if /^\s*$/ }
my @lines;
while () { last if /^\s*$/; push @lines, $_ }
my $decoded = decode_base64 join('', @lines);
$decoded =~ tr/\r//d;
print(encode_base64 $decoded);
print "\n"
}
}
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 01/36] test/T750-gzip: don't compress the xapian database

2021-01-11 Thread Tomi Ollila
On Sun, Jan 10 2021, David Bremner wrote:

> Tomi Ollila  writes:
>
>> On Sun, Jan 03 2021, David Bremner wrote:
>>
>>> +find ${MAIL_DIR} -name .notmuch -prune -false -o  -type f  -exec gzip 
>>> --recursive {} \;
>>
>> (some extra spaces above)
>>
>> The point of -false is that if there exists .notmuch which is file, then
>> include it ? (w/o -false the -o part is not included as -prune is true).
>>
> I think the -false is just a mistake.  For some reason I thought it was
> needed to avoid descending into .notmuch
>
>> I'd suggest
>>
>> find ${MAIL_DIR} -name .notmuch -prune -false -o -type f -print0 | xargs -0 
>> gzip --
>>
>
> what is the advantage of xargs here, less execs?

less forks and execs -- pid's don't run to very large values so soon
(it depends whether there are 3 or more files to be compressed, though :)

>
> d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org