da...@tethera.net writes:
From: David Bremner brem...@debian.org
The behaviour of emacsclient --eval nil changed from emacs23 to
emacs24, and in emacs24 it prints 'nil' rather than an empty string.
pushed,
d
___
notmuch mailing list
LGTM.
Quoth david at tethera.net on Aug 30 at 8:24 pm:
> From: David Bremner
>
> The version of message.el in emacs24 omits the charset=us-ascii,
> causing the current version of this test to fail. With this patch, we
> accept either option. According to RFC 2046, they are semantically
>
LGTM. Alternatively, the test could be
(null (notmuch-wash))
with the correct answer being 't'. That would avoid the awkward
detour through a string, but either way is good as long as this test
passes.
Quoth david at tethera.net on Aug 30 at 10:09 pm:
> From: David Bremner
>
> The
On Fri, Aug 31 2012, david at tethera.net wrote:
> From: David Bremner
>
> The version of message.el in emacs24 omits the charset=us-ascii,
> causing the current version of this test to fail. With this patch, we
> accept either option. According to RFC 2046, they are semantically
> equivalent.
On Fri, Aug 31 2012, Austin Clements wrote:
> LGTM. Alternatively, the test could be
> (null (notmuch-wash))
> with the correct answer being 't'. That would avoid the awkward
> detour through a string, but either way is good as long as this test
> passes.
I was going to vote this (null
On Fri, Aug 31 2012, Tomi Ollila wrote:
> On Fri, Aug 31 2012, Austin Clements wrote:
>
>> LGTM. Alternatively, the test could be
>> (null (notmuch-wash))
>> with the correct answer being 't'. That would avoid the awkward
>> detour through a string, but either way is good as long as
david at tethera.net writes:
> From: David Bremner
>
> The behaviour of "emacsclient --eval nil" changed from emacs23 to
> emacs24, and in emacs24 it prints 'nil' rather than an empty string.
pushed,
d
david at tethera.net writes:
> From: David Bremner
>
> The version of message.el in emacs24 omits the charset=us-ascii,
> causing the current version of this test to fail. With this patch, we
> accept either option. According to RFC 2046, they are semantically
> equivalent.
Pushed the second
On Fri, Aug 03 2012, Svend Sorensen wrote:
>
> I was also getting an error about gnus-inhibit-images when running emacs
> 24. Adding (require 'gnus-art) to my emacs config fixed the problem.
Where is your emacs24 from? From Debian sid?
David has some gnus-inhibit-images related tests failing
Tomi Ollila writes:
> On Fri, Aug 03 2012, Svend Sorensen wrote:
>
>>
>> I was also getting an error about gnus-inhibit-images when running emacs
>> 24. Adding (require 'gnus-art) to my emacs config fixed the problem.
>
> Where is your emacs24 from? From Debian sid?
I've been having the
Jameson Graef Rollins writes:
> No functional change.
>
> Most notmuch-show mode tests were in the emacs script, while some were
> in the emacs-show script. This moves all the notmuch-show mode tests
> to the emacs-show script, to make things a little more consistent.
This seems harmless
Jameson Graef Rollins writes:
>
> Ah, I didn't notice that:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=674032
>
> Encouragingly, it sounds like Jeffery is working on it.
FYI it's marked fixed in upstream git now.
d
Mark Walters writes:
> ---
> test/notmuch-test |1 +
> test/show | 47 +++
> 2 files changed, 48 insertions(+), 0 deletions(-)
> create mode 100755 test/show
Hi Mark;
This series was tagged stale at some point, but I imagine the
Pieter Praet writes:
> Demonstrates that *every* file/directory which matches one of the values
> in 'new.ignore' will be ignored, independent of its depth/location in
> the mail store.
> ---
This test fails, apparently because it hard codes the test file paths.
Otherwise the remainder of the
14 matches
Mail list logo
