From: David Bremner
Since notmuch dump doesn't use positional arguments anymore, it seems
better to be consistent.
---
man/man1/notmuch-restore.1 |2 +-
notmuch-restore.c |2 +-
test/dump-restore |8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --
From: David Bremner
The syntax --output=filename is a smaller change than deleting the
output argument completely, and conceivably useful e.g. when running
notmuch under a debugger.
---
man/man1/notmuch-dump.1 |5 ++---
notmuch-dump.c |3 +--
test/dump-restore | 20 +
The positional argument to dump was deprecated quite a while ago. For
restore, we never formally deprecated it. It seems a bit more
consistent this way, but I don't mind leaving restore alone if people
feel strongly about it.
Austin Clements writes:
> Relative to version 2 [0], this version fixes a duplicate typedef of
> struct sprinter that was not standards compliant and failed to compile
> on older gccs [1] (thanks to Tomi for discovering that and figuring
> out what was going on).
pushed.
d
From: David Bremner
Since notmuch dump doesn't use positional arguments anymore, it seems
better to be consistent.
---
man/man1/notmuch-restore.1 |2 +-
notmuch-restore.c |2 +-
test/dump-restore |8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --
From: David Bremner
The syntax --output=filename is a smaller change than deleting the
output argument completely, and conceivably useful e.g. when running
notmuch under a debugger.
---
man/man1/notmuch-dump.1 |5 ++---
notmuch-dump.c |3 +--
test/dump-restore | 20 +
The positional argument to dump was deprecated quite a while ago. For
restore, we never formally deprecated it. It seems a bit more
consistent this way, but I don't mind leaving restore alone if people
feel strongly about it.
___
notmuch mailing list
Quoth Michal Nazarewicz on Aug 03 at 4:29 pm:
> Hello everyone,
>
> I've just started using notmuch and am wondering if there is a way to
> make message ?inherit? some of the tags from messages they are written
> in replay to (or in general are part of the same thread).
>
> I'm mostly thinking a
Code LGTM, but maybe the comment should explain that this is a
workaround for a bug in Emacs, given that both sleep-for and sit-for
are supposed to process process output and run sentinels (which has
been stated in the Elisp reference at least as far back as Emacs 21).
In light of this (and our bet
Austin Clements writes:
> Relative to version 2 [0], this version fixes a duplicate typedef of
> struct sprinter that was not standards compliant and failed to compile
> on older gccs [1] (thanks to Tomi for discovering that and figuring
> out what was going on).
pushed.
d
_
chmail.org/pipermail/notmuch/attachments/20120803/035010cc/attachment.pgp>
The function `notmuch-test-wait` called `get-buffer-process` and
`sleep-for` in a loop. On some emacses neither of these cause emacs
to check whether the process has exited and update it's status
accordingly. In this case the loop does not exit.
The function `sit-for` goes into event loop via `rea
---
man/man7/notmuch-search-terms.7 | 147 +++
1 file changed, 135 insertions(+), 12 deletions(-)
diff --git a/man/man7/notmuch-search-terms.7 b/man/man7/notmuch-search-terms.7
index b8ab52d..cec3785 100644
--- a/man/man7/notmuch-search-terms.7
+++ b/man/man7/
Build a date/time parser as part of the notmuch lib, to be used for
adding date range query support later on.
Signed-off-by: Jani Nikula
---
lib/Makefile.local |1 +
lib/parse-time-string.c | 1384 +++
lib/parse-time-string.h | 95
3 fi
A brief initial test set.
---
test/notmuch-test |1 +
test/search-date | 21 +
2 files changed, 22 insertions(+)
create mode 100755 test/search-date
diff --git a/test/notmuch-test b/test/notmuch-test
index 80e687e..1654eb6 100755
--- a/test/notmuch-test
+++ b/test/notm
Add a custom value range processor to enable date and time searches of
the form date:since..until, where "since" and "until" are expressions
understood by the previously added date/time parser, to restrict the
results to messages within a particular time range (based on the Date:
header).
If "sinc
Test the date/time parser module directly. Just a small sanity test
initially.
---
test/notmuch-test |1 +
test/parse-time-string | 26 ++
2 files changed, 27 insertions(+)
create mode 100755 test/parse-time-string
diff --git a/test/notmuch-test b/test/notmuch-
Add a tool to support testing the date/time parser module directly and
independent of the rest of notmuch.
---
test/Makefile.local |9 +++-
test/basic |2 +-
test/parse-time.c | 145 +++
3 files changed, 153 insertions(+), 3 delet
-Wswitch-enum is a bit awkward if a switch statement is intended to
handle just some of the named codes of an enumeration especially, and
leave the rest to the default label.
We already have -Wall, which enables -Wswitch by default, and per GCC
documentation, "The only difference between -Wswitch
Hi all, this series adds a decent date range query support to the
notmuch lib. For example:
$ notmuch search date:2012-01-01..2012-02-01
$ notmuch search date:10:00..13:00
$ notmuch search date:monday..friday
$ notmuch search date:2months5days..2weeks5hours
$ notmuch search date:last-week..ye
Quoth Michal Nazarewicz on Aug 03 at 4:29 pm:
> Hello everyone,
>
> I've just started using notmuch and am wondering if there is a way to
> make message “inherit” some of the tags from messages they are written
> in replay to (or in general are part of the same thread).
>
> I'm mostly thinking a
Code LGTM, but maybe the comment should explain that this is a
workaround for a bug in Emacs, given that both sleep-for and sit-for
are supposed to process process output and run sentinels (which has
been stated in the Elisp reference at least as far back as Emacs 21).
In light of this (and our bet
Hello everyone,
I've just started using notmuch and am wondering if there is a way to
make message “inherit” some of the tags from messages they are written
in replay to (or in general are part of the same thread).
I'm mostly thinking about a “mute” tag which I'd add to messages that
are complete
On Fri, Aug 03 2012, Austin Clements wrote:
> Relative to version 2 [0], this version fixes a duplicate typedef of
> struct sprinter that was not standards compliant and failed to compile
> on older gccs [1] (thanks to Tomi for discovering that and figuring
> out what was going on).
LGTM.
Tomi
Robert Horn writes:
> I didn't find a reference to this bug, but before digging in deeper I'll
> ask if this is a duplicate. When viewing the same email message using
> emacs 24.1 and 23.3.1 I get an error in 24.1.
>
> The error is:
> mm-inline-text-html: Symbol's value as variable is void:
> g
Robert Horn writes:
> I didn't find a reference to this bug, but before digging in deeper I'll
> ask if this is a duplicate. When viewing the same email message using
> emacs 24.1 and 23.3.1 I get an error in 24.1.
>
> The error is:
> mm-inline-text-html: Symbol's value as variable is void:
> g
Robert Horn writes:
> I didn't find a reference to this bug, but before digging in deeper I'll
> ask if this is a duplicate. When viewing the same email message using
> emacs 24.1 and 23.3.1 I get an error in 24.1.
>
> The error is:
> mm-inline-text-html: Symbol's value as variable is void:
> g
David Bremner writes:
> There is some discussion in the thread starting at
> id:"1324309559-7993-1-git-send-email-dme at dme.org"; basically it seems to
> be a gnus bug, but maybe we should work around it some how. It was
> supposed to be fixed upstream in gnus, but apparently not.
>
I can wait
I didn't find a reference to this bug, but before digging in deeper I'll
ask if this is a duplicate. When viewing the same email message using
emacs 24.1 and 23.3.1 I get an error in 24.1.
The error is:
mm-inline-text-html: Symbol's value as variable is void:
gnus-inhibit-images
Notmuch is vers
David Bremner writes:
> There is some discussion in the thread starting at
> id:"1324309559-7993-1-git-send-email-...@dme.org"; basically it seems to
> be a gnus bug, but maybe we should work around it some how. It was
> supposed to be fixed upstream in gnus, but apparently not.
>
I can wait on
Robert Horn writes:
> I didn't find a reference to this bug, but before digging in deeper I'll
> ask if this is a duplicate. When viewing the same email message using
> emacs 24.1 and 23.3.1 I get an error in 24.1.
>
> The error is:
> mm-inline-text-html: Symbol's value as variable is void:
> g
The function `notmuch-test-wait` called `get-buffer-process` and
`sleep-for` in a loop. On some emacses neither of these cause emacs
to check whether the process has exited and update it's status
accordingly. In this case the loop does not exit.
The function `sit-for` goes into event loop via `rea
I didn't find a reference to this bug, but before digging in deeper I'll
ask if this is a duplicate. When viewing the same email message using
emacs 24.1 and 23.3.1 I get an error in 24.1.
The error is:
mm-inline-text-html: Symbol's value as variable is void:
gnus-inhibit-images
Notmuch is vers
On Fri, Aug 03 2012, Austin Clements wrote:
> Relative to version 2 [0], this version fixes a duplicate typedef of
> struct sprinter that was not standards compliant and failed to compile
> on older gccs [1] (thanks to Tomi for discovering that and figuring
> out what was going on).
LGTM.
Tomi
On Thu, Aug 02 2012, Austin Clements wrote:
> Quoth Jameson Graef Rollins on Aug 01 at 8:10 pm:
>> On Wed, Aug 01 2012, David Bremner wrote:
>> > As I mentioned on IRC, the test only fails on the Debian build machines
>> > (building in a clean chroot using sbuild is not enough) so it isn't
>> >
35 matches
Mail list logo
