The process-lines function calls the notmuch binary. The location of
the binary may have been customized by the user, so it is better to
use the customized location rather than allowing the process-lines
function to search the user's PATH for the binary.
---
emacs/notmuch.el |2 +-
1 files
patch against gnus works for
me. (I have tried submitting it to the gnus bug list, but have not been
able to check if it got through.)
Cheers,
Chris
commit 45e5a06ea63d8d9f9a962db7d739c7d7056ef712 (HEAD, refs/heads/master)
Author: Chris Gray chrismg...@gmail.com
Date: Mon Dec 19 23:33:30 2011
On Tue, 20 Dec 2011 08:35:42 +, David Edmondson d...@dme.org wrote:
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote:
+ (makunbound 'gnus-summary-buffer) ; Blech.
This is working around a bug in gnus. I think the better solution would
be for gnus
On Tue, 20 Dec 2011 14:33:01 +, David Edmondson d...@dme.org wrote:
On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray chrismg...@gmail.com wrote:
On Tue, 20 Dec 2011 08:35:42 +, David Edmondson d...@dme.org wrote:
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com
On Tue, 20 Dec 2011 03:40:44 -0500, Aaron Ecay aarone...@gmail.com wrote:
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote:
This is working around a bug in gnus.
Arguably this is true, but the real “bug” (conceptual error) is that the
MIME handling libraries
On Mon, 23 Jan 2012 15:43:08 +0100, Florian Friesdorf f...@chaoflow.net wrote:
With notmuch-0.11 (require 'gnus-art') fixes the void
gnus-inhibit-images error.
This is true, though as Aaron Ecay pointed out in the discussion of this
patch, it does bring in all of gnus. My current workaround to
Hi,
My thinking about this arises from the fact that there is a person on
one of the lists that I read who puts a semicolon after his name. Of
course, this confuses the regex in notmuch-search-process-filter, which
expects that the first semicolon in the string representing a thread is
after all
The process-lines function calls the notmuch binary. The location of
the binary may have been customized by the user, so it is better to
use the customized location rather than allowing the process-lines
function to search the user's PATH for the binary.
---
emacs/notmuch.el |2 +-
1 files
-images nil))
> + (makunbound 'gnus-summary-buffer) ; Blech.
This is working around a bug in gnus. I think the better solution would
be for gnus to fix the bug. The following patch against gnus works for
me. (I have tried submitting it to the gnus bug list, but have not been
able to check
On Tue, 20 Dec 2011 08:35:42 +, David Edmondson wrote:
> On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray
> wrote:
> > > + (makunbound 'gnus-summary-buffer) ; Blech.
> >
> > This is working around a bug in gnus. I think the better solution would
>
On Tue, 20 Dec 2011 14:33:01 +, David Edmondson wrote:
> On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray
> wrote:
> > On Tue, 20 Dec 2011 08:35:42 +, David Edmondson wrote:
> > > On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray
> > > wrote:
> > &
On Tue, 20 Dec 2011 03:40:44 -0500, Aaron Ecay wrote:
> On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray
> wrote:
> > This is working around a bug in gnus.
>
> Arguably this is true, but the real ?bug? (conceptual error) is that the
> MIME handling libraries and gnus are
On Mon, 23 Jan 2012 15:43:08 +0100, Florian Friesdorf
wrote:
> With notmuch-0.11 (require 'gnus-art') "fixes" the void
> gnus-inhibit-images error.
This is true, though as Aaron Ecay pointed out in the discussion of this
patch, it does bring in all of gnus. My current workaround to the bug
of
Hi,
My thinking about this arises from the fact that there is a person on
one of the lists that I read who puts a semicolon after his name. Of
course, this confuses the regex in notmuch-search-process-filter, which
expects that the first semicolon in the string representing a thread is
after all
14 matches
Mail list logo
