Re: Possible bug: incorrect processing of multipart, base64-encoded subject lines.
* Thibault Polge , 2022-09-21 16:15: Subject: =?UTF-8?B?TGl2cmFpc29uIHByw6l2dWUgcG91ciBhdWpvdXJk4oCZaHU=?= =?UTF-8?B?aTogUkVTVFJBUCBTYWRkbGUgQmFnIFNhY2NvY2hlLi4u?= Notmuch displays the subject as only the decoded contents of the first fragment I believe this is now fixed in GMime upstream: https://github.com/jstedfast/gmime/commit/1a33a55baafc73b0 -- Jakub Wilk ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Bug#1021614: notmuch: RFC2047-encoded special characters in display-name show up unquoted
Attaching the reprocucer scripts, which somehow got lost in transport!?
--
Jakub Wilk
#!/bin/bash
set -e -u
tmpdir="$(mktemp -d)"
export NOTMUCH_DATABASE="$tmpdir"
notmuch --config '' new > /dev/null
mkdir -p "$NOTMUCH_DATABASE"/{cur,new,tmp}
notmuch --config '' insert > /dev/null
notmuch --config '' show '*' | grep ^From:
rm -rf "tmpdir"
#!/usr/bin/python3
import sys
import gi
gi.require_version('GMime', '3.0')
from gi.repository import GMime
GMime.init()
stream = GMime.StreamPipe.new(sys.stdin.fileno())
parser = GMime.Parser.new_with_stream(stream)
msg = parser.construct_message()
addrs = msg.get_from()
addrs = addrs.to_string(GMime.FormatOptions(), True)
print('From:', addrs)
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Bug#1021614: notmuch: RFC2047-encoded special characters in display-name show up unquoted
Package: notmuch Version: 0.37-1 The attached message has a bunch of RFC-2047-encoded special characters in the display-name part of the From field: $ grep ^From: weird-from.eml From: =?UTF-8?Q?=3Cfoo=40example.org=3E=2C?= When you show this message in notmuch, the special characters show up unquoted (and unencoded), so that it looks like there are two addresses in the From field: $ ./notmuch-show-from < weird-from.eml From: , I initially thought this is a GMime bug, but it seems GMime gets this right: $ ./gmime-show-from < weird-from.eml From: "," -- System Information: Architecture: i386 Versions of packages notmuch depends on: ii libnotmuch5 0.37-1 ii libc6 2.35-3 ii libglib2.0-02.74.0-2 ii libgmime-3.0-0 3.2.13+dfsg-2 ii libtalloc2 2.3.4-1 ii zlib1g 1:1.2.11.dfsg-4.1 -- Jakub Wilk --- Begin Message --- --- End Message --- ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] nmweb: Fix spacing around punctuation in headers
Jakub Wilk writes: > * David Bremner , 2022-10-11 08:20: >>>This is completely untested, but hey, what could possibly go wrong? >> >>I've yolo-ed this into production on nmbug.notmuchmail.org. Maybe you >>can poke at it and see if it looks like you expect. > > Looks good. Thanks! > applied to master. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Selection bug
Justus Winter writes:
> I think I found a reproducer:
>
> mkdir -p /tmp/selection-bug/{tmp,new,cur}
> echo "[database]
> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch new
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config emacs -q --eval "(require
> 'notmuch)"
> # M-x notmuch-hello, search for '*'
> notmuch show --format=raw id:87edvlanuh@tethera.net |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, press down once, i.e. navigate to "End of search
> results".
> notmuch show --format=raw id:87fsfuuxwn.fsf@thinkbox |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> notmuch show --format=raw id:8735buw7gf@ngraves.fr |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, bug: Nicolas' mail is green, mine is opened on
> pressing enter.
1) Do you think the particular messages matter? I don't have
id:8735buw7gf@ngraves.fr
2) Just to be clear, that script has to be run manually, with the
comments corresponding to interactive actions in emacs?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] cli: add options --offset and --limit to notmuch show
On Wed, Oct 12 2022, Robin Jarry wrote:
> Hi Tomi,
>
> Tomi Ollila, Oct 12, 2022 at 21:39:
>> > diff --git a/notmuch-show.c b/notmuch-show.c
>> > index ee9efa7448d7..ad31e0123268 100644
>> > --- a/notmuch-show.c
>> > +++ b/notmuch-show.c
>> > @@ -1159,6 +1159,18 @@ do_show_threaded (void *ctx,
>> > notmuch_thread_t *thread;
>> > notmuch_messages_t *messages;
>> > notmuch_status_t status, res = NOTMUCH_STATUS_SUCCESS;
>> > +int i;
>> > +
>> > +if (params->offset < 0) {
>> > + unsigned count;
>> > + notmuch_status_t s = notmuch_query_count_threads (query, );
>> > + if (print_status_query ("notmuch search", query, s))
>> > + return 1;
>> > +
>> > + params->offset += count;
>> > + if (params->offset < 0)
>>
>> this check and setting it to 0 is mystic to me, probably same code as in
>> search (?) probably it is good (?) (will not comment the same below)
>
> Yes, I copy/pasted that code from notmuch-search.c. I believe this to
> handle the case where:
>
> --limit=N && --offset=-M && M > count
>
> After adding count to offset, you may end up with a negative offset
> which makes the loop exit condition invalid and the --limit value would
> not be enforced as expected:
>
> i < params->offset + params->limit
>
>> > diff --git a/test/T131-show-limiting.sh b/test/T131-show-limiting.sh
>> > new file mode 100755
>> > index ..a3da35944a3e
>> > --- /dev/null
>> > +++ b/test/T131-show-limiting.sh
>> > @@ -0,0 +1,81 @@
>> > +#!/usr/bin/env bash
>> > +test_description='"notmuch show" --offset and --limit parameters'
>> > +. $(dirname "$0")/test-lib.sh || exit 1
>> > +
>> > +add_email_corpus
>> > +
>> > +function show() {
>>
>> 'function' not used in other function defitions in other files, so this is
>> inconsistent (otherwise the content looks "better" than what I see usual ;D)
>
> I concur that this is a bash-only construct. I could remove the function
> keyword and we would have the same result.
Bash constructs are allowed (even perhaps encouraged in many cases), I just
care about consistency (it is easier to browse through large set of files
if there is not too much differenct constructs used)
In case of 'function' it also works in zsh (and probably ksh). I have
started to use in all (except one, I just noticed) function definitions
in my zshrc. I recall I had a problem which using function fixed
-- probably related to something with
ff () { ...; }
alias ff='noglob ff'
which did not exactly worked like it should have. function ff () { ...; }
fixed that case (cannot remember exact details, changed 2021-03-08 w/
somewhat vague git commit message (in private dotdir repo :)))
>
>> > +test_begin_subtest "${outp}: offset = 0"
>>
>> inconsistent ${outp} (where $outp used elsewhere) ...
>
> Indeed. I had removed all the ${} except this one. For consistency with
> the other test scripts, I could add them back everywhere. I don't mind
> either way.
I personally prefer w/o {} in trivial cases, shorter and clearer to read
(and use $FOO''bar instead of ${FOO}bar when such need arrives ;/). that
is such a small difference (IMO) that either goes...
>
> I'll hold off for other remarks before sending a v2.
>
> Cheers,
Tomi
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
