On Mon, Apr 21 2014, Austin Clements wrote:
> I set out to quickly add support for cid: links in the shr renderer
> and wound up making our charset handling more robust and rewriting our
> content-ID handling. The test introduced in patch 2 passes in all but
> one really obscure case, but only b
"W. Trevor King" writes:
> I just bumped into this today while testing v2 of my
> content-description series:
>
pushed patches 1-4
d
Mark Walters writes:
> The recent changes for saved searches introduced a bug when notmuch
> was loaded after the saved search was defined. This was caused by a
> utility function not being defined when the defcustom was loaded.
pushed.
d
Austin Clements writes:
> This is v2 of id:1397834332-25175-1-git-send-email-amdragon at mit.edu.
> It expands the explanation of "non-MIME" message parts and moves it to
> the --part documentation.
pushed.
d
These tests deliver all possible (single-root) four-message threads in
all possible orders and check that notmuch successfully links them
into threads.
There are two variants of the test: one delivers messages that
reference only their immediate parent and the other delivers messages
that referenc
shr has really nice support for inline image rendering, but previously
we only had the hooks for w3m cid: references.
---
emacs/notmuch-show.el | 41 +
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.
Besides generally cleaning up the code and separating the general
content ID handling from the w3m-specific code, this fixes several
problems.
Foremost is that, previously, the code roughly assumed that referenced
parts would be in the same multipart/related as the reference.
According to RFC 2392
Previously this did its own caching, but this is now supported by more
generally by `notmuch-get-bodypart-binary'.
---
emacs/notmuch-show.el | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 537c558..941
(The actual code change here is small, but requires re-indenting
existing code.)
---
emacs/notmuch-lib.el | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index fc67b14..fee8512 10
Unibyte strings are meant for representing binary data. In practice,
using unibyte versus multibyte strings affects *almost* nothing. It
does happen to matter if we use the binary data in an image descriptor
(which is, helpfully, not documented anywhere and getting it wrong
results in opaque erro
`notmuch-get-bodypart-content' could do two very different things,
depending on conditions: for text/* parts other than text/html, it
would return the part content as a multibyte Lisp string *after*
charset conversion, while for other parts (including text/html), it
would return binary part content
The new function, `notmuch-get-bodypart-binary', replaces
`notmuch-get-bodypart-internal'. Whereas the old function was really
meant for internal use in `notmuch-get-bodypart-content', it was used
in a few other places. Since the difference between
`notmuch-get-bodypart-content' and `notmuch-get-
This will simplify later changes.
---
emacs/notmuch-show.el | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2b225df..455cfee 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@
This fixes the known-broken test of viewing 8bit messages added by the
previous commit.
---
emacs/notmuch-show.el | 5 +++--
test/T455-emacs-charsets.sh | 1 -
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 949ac09..2b225df
The test of viewing 8bit messages is known-broken. The rest pass, but
for very fragile reasons. The next several commits will fix the
known-broken test and make our charset handling robust.
---
test/T455-emacs-charsets.sh | 141
test/test-lib.el
This can be derived from the PART argument (which is arguably
canonical), so there's no sense in giving the caller an extra foot
gun.
---
emacs/notmuch-lib.el | 9 +
emacs/notmuch-show.el | 6 +++---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/emacs/notmuch-lib.el b/ema
I set out to quickly add support for cid: links in the shr renderer
and wound up making our charset handling more robust and rewriting our
content-ID handling. The test introduced in patch 2 passes in all but
one really obscure case, but only because of many unwritten and
potentially fragile assum
On Mon, Apr 21 2014, Austin Clements wrote:
> I set out to quickly add support for cid: links in the shr renderer
> and wound up making our charset handling more robust and rewriting our
> content-ID handling. The test introduced in patch 2 passes in all but
> one really obscure case, but only b
These tests deliver all possible (single-root) four-message threads in
all possible orders and check that notmuch successfully links them
into threads.
There are two variants of the test: one delivers messages that
reference only their immediate parent and the other delivers messages
that referenc
Quoth Mark Walters on Apr 21 at 8:20 am:
>
> >> I haven't tracked through all the logic of the existing algorithm for
> >> this case. But I don't like hearing that notmuch constructs different
> >> threads for the same messages presented in different orders. This sounds
> >> like a bug separate f
The new function, `notmuch-get-bodypart-binary', replaces
`notmuch-get-bodypart-internal'. Whereas the old function was really
meant for internal use in `notmuch-get-bodypart-content', it was used
in a few other places. Since the difference between
`notmuch-get-bodypart-content' and `notmuch-get-
Unibyte strings are meant for representing binary data. In practice,
using unibyte versus multibyte strings affects *almost* nothing. It
does happen to matter if we use the binary data in an image descriptor
(which is, helpfully, not documented anywhere and getting it wrong
results in opaque erro
This will simplify later changes.
---
emacs/notmuch-show.el | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2b225df..455cfee 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@
shr has really nice support for inline image rendering, but previously
we only had the hooks for w3m cid: references.
---
emacs/notmuch-show.el | 41 +
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.
(The actual code change here is small, but requires re-indenting
existing code.)
---
emacs/notmuch-lib.el | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index fc67b14..fee8512 10
`notmuch-get-bodypart-content' could do two very different things,
depending on conditions: for text/* parts other than text/html, it
would return the part content as a multibyte Lisp string *after*
charset conversion, while for other parts (including text/html), it
would return binary part content
Previously this did its own caching, but this is now supported by more
generally by `notmuch-get-bodypart-binary'.
---
emacs/notmuch-show.el | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 537c558..941
I set out to quickly add support for cid: links in the shr renderer
and wound up making our charset handling more robust and rewriting our
content-ID handling. The test introduced in patch 2 passes in all but
one really obscure case, but only because of many unwritten and
potentially fragile assum
This can be derived from the PART argument (which is arguably
canonical), so there's no sense in giving the caller an extra foot
gun.
---
emacs/notmuch-lib.el | 9 +
emacs/notmuch-show.el | 6 +++---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/emacs/notmuch-lib.el b/ema
This fixes the known-broken test of viewing 8bit messages added by the
previous commit.
---
emacs/notmuch-show.el | 5 +++--
test/T455-emacs-charsets.sh | 1 -
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 949ac09..2b225df
Austin Clements writes:
> But let me propose an idea I've been kicking around for a while: ghost
> message documents. Rather than using user metadata for tracking these
> missing messages, use regular documents with the exact same terms we
> use now for message IDs and thread IDs, but with a Tgho
Quoth Mark Walters on Apr 21 at 8:20 am:
>
> >> I haven't tracked through all the logic of the existing algorithm for
> >> this case. But I don't like hearing that notmuch constructs different
> >> threads for the same messages presented in different orders. This sounds
> >> like a bug separate f
>> I haven't tracked through all the logic of the existing algorithm for
>> this case. But I don't like hearing that notmuch constructs different
>> threads for the same messages presented in different orders. This sounds
>> like a bug separate from what we've discussed above.
I think I have now
Tomi Ollila writes:
> In this series IMO the patches 1-4:
>
> id:8d518408f2da8bc96ae3123f05791142da26b9bc.1396718720.git.wking at tremily.us
> id:543aee63407956e60f85dc11a2d25855e98c10c3.1396718720.git.wking at tremily.us
> id:5e4509ab08699afe2681110fb35075e1d0bbdc7e.1396718720.git.wking at tremi
David Bremner writes:
> Since 'notmuch new' now takes multiple options, it's confusing to show
> only one of them in the summary.
pushed,
d
Mark Walters writes:
> ---
> Fixed the markdown and the bracket error.
pushed.
d
"W. Trevor King" writes:
> I just bumped into this today while testing v2 of my
> content-description series:
>
pushed patches 1-4
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Mark Walters writes:
> The recent changes for saved searches introduced a bug when notmuch
> was loaded after the saved search was defined. This was caused by a
> utility function not being defined when the defcustom was loaded.
pushed.
d
___
notmuch
Austin Clements writes:
> This is v2 of id:1397834332-25175-1-git-send-email-amdra...@mit.edu.
> It expands the explanation of "non-MIME" message parts and moves it to
> the --part documentation.
pushed.
d
___
notmuch mailing list
notmuch@notmuchmail.
>> I haven't tracked through all the logic of the existing algorithm for
>> this case. But I don't like hearing that notmuch constructs different
>> threads for the same messages presented in different orders. This sounds
>> like a bug separate from what we've discussed above.
I think I have now
40 matches
Mail list logo