"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
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
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
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
(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
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
`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
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
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
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
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
>> 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
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
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
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 found
Austin Clements amdra...@mit.edu 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
Mark Walters markwalters1...@gmail.com 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
W. Trevor King wk...@tremily.us 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
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 from what
Austin Clements amdra...@mit.edu 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,
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
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
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
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
(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
`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
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
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
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
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
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
On Mon, Apr 21 2014, Austin Clements amdra...@mit.edu 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
39 matches
Mail list logo
