LGTM
On Wed, 06 Mar 2013, Aaron Ecay wrote:
> Presently, the code which finds the parent of a message as it is being
> added to the database assumes that the first Message-ID-like substring
> of the In-Reply-To header is the parent Message ID. Some mail clients,
> however, put stuff other than
On Wed, 06 Mar 2013, Aaron Ecay wrote:
> These tests are known_broken, the following commit fixes them.
> ---
>
> Thanks to David and Tomi for pointing out test_expect_equal_json. In
> the process of implementing that, I discovered
> notmuch_json_show_sanitize, which I had also not been using.
Austin Clements writes:
> ---
> bindings/python/notmuch/thread.py | 27 ++-
Justus OKed this privately.
d
This adds the actual code to do the lazy insertion of hidden parts.
We use a memory inefficient but simple method: when we come to insert
the part if it is hidden we just store all of the arguments to the
part insertion function as a button property. This means when we want
to show the part we
Previously each of the part insertion handlers inserted the part
button themselves. Move this up into
notmuch-show-insert-bodypart. Since a small number of the handlers
modify the button (the encryption/signature ones) we need to pass the
header button as an argument into the individual part
The inline patch fake part handler also modifies the content-type so
handle this in notmuch-show-insert-bodypart too.
---
emacs/notmuch-show.el |4 +++-
emacs/notmuch-wash.el |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el
Currently mime parts are basically handled based on their mime-type
with the exception of application/octet-stream parts. Deal with these
parts at the top level (notmuch-show-insert-bodypart).
This is needed later in the series as we need to put in a part button
for each part (which means knowing
This is a much better version of the WIP patch at
id:1367628568-11656-1-git-send-email-markwalters1009 at gmail.com
There was some discussion on irc about the new invisibility handling
making large threads of messages with html parts slow to appear. This
is caused by the new code rendering all of
Jani Nikula writes:
> On Fri, 03 May 2013, Servilio Afre Puentes wrote:
>> Two patches that enhance the notmuch-hello search history UI. Though
>> minor I find them very helpful.
>
> Both seem to work as advertised; I did not look at the code much. A
> minor bikeshed is that I think y-or-n-p
On Fri, 03 May 2013, Servilio Afre Puentes wrote:
> Two patches that enhance the notmuch-hello search history UI. Though
> minor I find them very helpful.
Both seem to work as advertised; I did not look at the code much. A
minor bikeshed is that I think y-or-n-p would suffice in patch 1/2.
BR,
Aaron Ecay writes:
> +if (ref && strcmp(ref, message_id)) {
> + return ref;
> +} else {
> + return NULL;
> +}
As a nit, there should be a space after strcmp. But if nobody has any
other comments, I could amend that.
d
Aaron Ecay writes:
> These tests are known_broken, the following commit fixes them.
> ---
On current master, I get
FIXED Use In-Reply-To when no References
d
The current code renders all html parts by default and then hides
them. This is quite slow so this is an attempt to make it only render
them when the user chooses to show them.
In my testing this code seems to work but has some rough
edges. However, it may be useful to people in its current form
Amadeusz ?o?nowski writes:
> Attached message, when opened, causes Emacs crash:
>
> *** glibc detected *** emacs: free(): invalid next size (fast):
> 0x0324f5e0 ***
As promised, I duplicated this without notmuch, so I reported upstream
as
On Fri, 03 May 2013, Servilio Afre Puentes servi...@gmail.com wrote:
Two patches that enhance the notmuch-hello search history UI. Though
minor I find them very helpful.
Both seem to work as advertised; I did not look at the code much. A
minor bikeshed is that I think y-or-n-p would suffice in
This is a much better version of the WIP patch at
id:1367628568-11656-1-git-send-email-markwalters1...@gmail.com
There was some discussion on irc about the new invisibility handling
making large threads of messages with html parts slow to appear. This
is caused by the new code rendering all of
Currently mime parts are basically handled based on their mime-type
with the exception of application/octet-stream parts. Deal with these
parts at the top level (notmuch-show-insert-bodypart).
This is needed later in the series as we need to put in a part button
for each part (which means knowing
The inline patch fake part handler also modifies the content-type so
handle this in notmuch-show-insert-bodypart too.
---
emacs/notmuch-show.el |4 +++-
emacs/notmuch-wash.el |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el
Previously each of the part insertion handlers inserted the part
button themselves. Move this up into
notmuch-show-insert-bodypart. Since a small number of the handlers
modify the button (the encryption/signature ones) we need to pass the
header button as an argument into the individual part
This adds the actual code to do the lazy insertion of hidden parts.
We use a memory inefficient but simple method: when we come to insert
the part if it is hidden we just store all of the arguments to the
part insertion function as a button property. This means when we want
to show the part we
Aaron Ecay aarone...@gmail.com writes:
These tests are known_broken, the following commit fixes them.
---
On current master, I get
FIXED Use In-Reply-To when no References
d
___
notmuch mailing list
notmuch@notmuchmail.org
Aaron Ecay aarone...@gmail.com writes:
These tests are known_broken, the following commit fixes them.
---
Sorry for the extra mails, but this patch also makes test/basic fail
because thread-replies is not added to test/notmuch-test
d
___
notmuch
Aaron Ecay aarone...@gmail.com writes:
+if (ref strcmp(ref, message_id)) {
+ return ref;
+} else {
+ return NULL;
+}
As a nit, there should be a space after strcmp. But if nobody has any
other comments, I could amend that.
d
Jani Nikula j...@nikula.org writes:
On Fri, 03 May 2013, Servilio Afre Puentes servi...@gmail.com wrote:
Two patches that enhance the notmuch-hello search history UI. Though
minor I find them very helpful.
Both seem to work as advertised; I did not look at the code much. A
minor bikeshed
On Wed, 06 Mar 2013, Aaron Ecay aarone...@gmail.com wrote:
These tests are known_broken, the following commit fixes them.
---
Thanks to David and Tomi for pointing out test_expect_equal_json. In
the process of implementing that, I discovered
notmuch_json_show_sanitize, which I had also not
LGTM
On Wed, 06 Mar 2013, Aaron Ecay aarone...@gmail.com wrote:
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put
Austin Clements amdra...@mit.edu writes:
---
bindings/python/notmuch/thread.py | 27 ++-
Justus OKed this privately.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Hi
This seems like a useful addition to me. I have a couple of comments and
a little bikeshedding below.
On Thu, 02 May 2013, Jani Nikula j...@nikula.org wrote:
We have most of the plumbing in place, add the bindings M-n and M-p.
---
emacs/notmuch-show.el | 24
1
These patches both look good to me (and the lisp all looks fine) modulo
a trivial style comment and a little bikeshedding.
For the bikeshedding I would prefer that the first patch was a y-or-n-p
(as Jani suggested) and that the second didn't query at all (the
dataloss potential from deleting a
29 matches
Mail list logo
