On Sat, 24 Jan 2015, "Jan N. Klug" wrote:
> On Sat, Jan 24, 2015 at 04:21:06PM +0100, Stefano Zacchiroli wrote:
>> On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
>> > On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
>> > > To do the above, rewrite get_message_id() to scan the current
On Sat, Jan 24, 2015 at 04:21:06PM +0100, Stefano Zacchiroli wrote:
> On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
> > On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> > > To do the above, rewrite get_message_id() to scan the current message
> > > line by line, incrementally comput
On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> From: "Jan N. Klug"
>
> For those messages, compute a synthetic Message-ID based on the SHA1
> of the whole message, in the same way that notmuch would do. See:
> http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/sha1.c
As I said on IRC, I thi
Todd writes:
> I think I've finished incorporating the feedback. The final
> notmuch-search-terms.rst could use more details, but it should
> probably occur after the recent patch that was posted documenting the
> probablistic indexing/searching has been committed.
Pushed this version, with ame
First of all thanks for your feedback, Jani!
(both here, and the other day on IRC, of course)
On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
> On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> >
> > For those messages, compute a synthetic Message-ID based on the SHA1
> > of the whole
shr has really nice support for inline image rendering, but previously
we only had the hooks for w3m cid: references.
---
emacs/notmuch-show.el | 45 +
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-s
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 f29428a..11e
(The actual code change here is small, but requires re-indenting
existing code.)
---
emacs/notmuch-lib.el | 64
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 3154725..f8e5165 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 87b4881..df2389e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@
This is v2 of id:1398105468-14317-1-git-send-email-amdragon at mit.edu.
This improves some comments/documentation, fixes a bug that caused
cryptographic processing to not happen on HTML parts, and addresses
some byte compiler warnings on Emacs 23. This version has also been
rebased against the sev
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-
shr has really nice support for inline image rendering, but previously
we only had the hooks for w3m cid: references.
---
emacs/notmuch-show.el | 45 +
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-s
(The actual code change here is small, but requires re-indenting
existing code.)
---
emacs/notmuch-lib.el | 64
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 3154725..f8e5165 10
This is v2 of id:1398105468-14317-1-git-send-email-amdra...@mit.edu.
This improves some comments/documentation, fixes a bug that caused
cryptographic processing to not happen on HTML parts, and addresses
some byte compiler warnings on Emacs 23. This version has also been
rebased against the severa
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 f29428a..11e
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 87b4881..df2389e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@
On Fri, 25 Apr 2014, Mark Walters wrote:
> On Thu, 24 Apr 2014, Austin Clements wrote:
>> Quoth Mark Walters on Apr 24 at 11:46 am:
>>>
>>> On Mon, 21 Apr 2014, Austin Clements wrote:
>>> > (The actual code change here is small, but requires re-indenting
>>> > existing code.)
>>> > ---
>>> > e
I added declare-functions for both of these, which should take care of
the Emacs 23 warnings and be more robust on Emacs 24. We can't reach
the function that calls these unless shr is actually available, but the
byte compiler doesn't know that.
On Sat, 26 Apr 2014, Mark Walters wrote:
> Aside fr
On Thu, 01 May 2014, David Edmondson wrote:
> On Mon, Apr 21 2014, Austin Clements wrote:
>> +(defun notmuch-show--insert-part-text/html-shr (msg part)
>> + ;; Make sure shr is loaded before we start let-binding its globals
>> + (require 'shr)
>> + (let ((dom (let (process-crypto notmuch-show-p
On Fri, 11 Jul 2014, David Bremner wrote:
> Austin Clements writes:
>
>> +This returns the content of the given part as a multibyte Lisp
>
> What does "multibyte" mean here? utf8? current encoding?
Elisp has two kinds of stings: "unibyte strings" and "multibyte
strings".
https://www.gnu.org/
On Sat, 24 Jan 2015, "Jan N. Klug" wrote:
> On Sat, Jan 24, 2015 at 04:21:06PM +0100, Stefano Zacchiroli wrote:
>> On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
>> > On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
>> > > To do the above, rewrite get_message_id() to scan the current
On Thu, 10 Jul 2014, David Bremner wrote:
> Austin Clements writes:
>
>> This will simplify later changes.
>
> I'd have preferred the whitespace changes as a seperate patch, but OK.
Not sure which whitespace changes you're referring to. Everything in
this diff is actual (minor) code changes.
David Bremner writes:
> Tomi Ollila writes:
>
>> In case we had doxygen but not sphinx notmuch.3 was created but
>> notmuch.3.gz not -- which means install fails!
>> This patch (with late night unpolished commit message will fix that)
>
> By install fails, you mean the man page is simply not ins
Rationale: the dependency is no longer needed after the rewrite of
get_message_id().
Note that Digest::SHA, needed by the new implementation of
get_message_id(), is shipped by the perl package itself, which is in
an implied dependency of other lib*-perl packages. So there is no need
to list perl e
From: "Jan N. Klug"
For those messages, compute a synthetic Message-ID based on the SHA1
of the whole message, in the same way that notmuch would do. See:
http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/sha1.c
To do the above, rewrite get_message_id() to scan the current message
line by li
---
contrib/notmuch-mutt/README | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/notmuch-mutt/README b/contrib/notmuch-mutt/README
index 382ac91..c661447 100644
--- a/contrib/notmuch-mutt/README
+++ b/contrib/notmuch-mutt/README
@@ -33,13 +33,13 @@ Requirements
Please find attached a patch series that add support for messages that
lack Message-ID to notmuch-mutt, kindly provided by Jan N. Klug. I've
reviewed / adapted it, and I consider it suitable for inclusion into
the next release of notmuch(-mutt).
Please let me know if you've any question.
Cheers.
On Fri, 25 Apr 2014, Mark Walters wrote:
> On Thu, 24 Apr 2014, Austin Clements wrote:
>> Quoth Mark Walters on Apr 24 at 11:46 am:
>>>
>>> On Mon, 21 Apr 2014, Austin Clements wrote:
>>> > (The actual code change here is small, but requires re-indenting
>>> > existing code.)
>>> > ---
>>> > e
Tomi Ollila writes:
> In case we had doxygen but not sphinx notmuch.3 was created but
> notmuch.3.gz not -- which means install fails!
> This patch (with late night unpolished commit message will fix that)
By install fails, you mean the man page is simply not installed? I agree
that's a bug, but
David Bremner writes:
> Jinwoo Lee writes:
>
>> Yup. It works! Thanks for the quick fix. Is this going to be merged
>> to HEAD soon?
>>
>
> Probably in the next day or so, unless somebody complains.
This bug should be fixed in commit cc3d25d
d
I added declare-functions for both of these, which should take care of
the Emacs 23 warnings and be more robust on Emacs 24. We can't reach
the function that calls these unless shr is actually available, but the
byte compiler doesn't know that.
On Sat, 26 Apr 2014, Mark Walters wrote:
> Aside fr
On Thu, 01 May 2014, David Edmondson wrote:
> On Mon, Apr 21 2014, Austin Clements wrote:
>> +(defun notmuch-show--insert-part-text/html-shr (msg part)
>> + ;; Make sure shr is loaded before we start let-binding its globals
>> + (require 'shr)
>> + (let ((dom (let (process-crypto notmuch-show-p
On Fri, 11 Jul 2014, David Bremner wrote:
> Austin Clements writes:
>
>> +This returns the content of the given part as a multibyte Lisp
>
> What does "multibyte" mean here? utf8? current encoding?
Elisp has two kinds of stings: "unibyte strings" and "multibyte
strings".
https://www.gnu.org/
On Sat, Jan 24, 2015 at 04:21:06PM +0100, Stefano Zacchiroli wrote:
> On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
> > On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> > > To do the above, rewrite get_message_id() to scan the current message
> > > line by line, incrementally comput
On Thu, 10 Jul 2014, David Bremner wrote:
> Austin Clements writes:
>
>> This will simplify later changes.
>
> I'd have preferred the whitespace changes as a seperate patch, but OK.
Not sure which whitespace changes you're referring to. Everything in
this diff is actual (minor) code changes.
__
Todd writes:
> I think I've finished incorporating the feedback. The final
> notmuch-search-terms.rst could use more details, but it should
> probably occur after the recent patch that was posted documenting the
> probablistic indexing/searching has been committed.
Pushed this version, with ame
First of all thanks for your feedback, Jani!
(both here, and the other day on IRC, of course)
On Sat, Jan 24, 2015 at 04:59:16PM +0200, Jani Nikula wrote:
> On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> >
> > For those messages, compute a synthetic Message-ID based on the SHA1
> > of the whole
On Sat, 24 Jan 2015, Stefano Zacchiroli wrote:
> From: "Jan N. Klug"
>
> For those messages, compute a synthetic Message-ID based on the SHA1
> of the whole message, in the same way that notmuch would do. See:
> http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/sha1.c
As I said on IRC, I thi
David Bremner writes:
> Tomi Ollila writes:
>
>> In case we had doxygen but not sphinx notmuch.3 was created but
>> notmuch.3.gz not -- which means install fails!
>> This patch (with late night unpolished commit message will fix that)
>
> By install fails, you mean the man page is simply not ins
---
contrib/notmuch-mutt/README | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/notmuch-mutt/README b/contrib/notmuch-mutt/README
index 382ac91..c661447 100644
--- a/contrib/notmuch-mutt/README
+++ b/contrib/notmuch-mutt/README
@@ -33,13 +33,13 @@ Requirements
From: "Jan N. Klug"
For those messages, compute a synthetic Message-ID based on the SHA1
of the whole message, in the same way that notmuch would do. See:
http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/sha1.c
To do the above, rewrite get_message_id() to scan the current message
line by li
Please find attached a patch series that add support for messages that
lack Message-ID to notmuch-mutt, kindly provided by Jan N. Klug. I've
reviewed / adapted it, and I consider it suitable for inclusion into
the next release of notmuch(-mutt).
Please let me know if you've any question.
Cheers.
Rationale: the dependency is no longer needed after the rewrite of
get_message_id().
Note that Digest::SHA, needed by the new implementation of
get_message_id(), is shipped by the perl package itself, which is in
an implied dependency of other lib*-perl packages. So there is no need
to list perl e
Tomi Ollila writes:
> In case we had doxygen but not sphinx notmuch.3 was created but
> notmuch.3.gz not -- which means install fails!
> This patch (with late night unpolished commit message will fix that)
By install fails, you mean the man page is simply not installed? I agree
that's a bug, but
David Bremner writes:
> Jinwoo Lee writes:
>
>> Yup. It works! Thanks for the quick fix. Is this going to be merged
>> to HEAD soon?
>>
>
> Probably in the next day or so, unless somebody complains.
This bug should be fixed in commit cc3d25d
d
___
51 matches
Mail list logo
