David Bremner writes:
The latter, I think. Thanks for pinging. It looks like that last
discussion was my comment about breaking the API. Any feedback
on that, either of you?
I don't see why making the argument optional wouldn't work. However, I
tried applying the patch and am not seeing a c
Was this proposal dropped or did it just get lost?
David Edmondson writes:
> If a text/plain part is declared as format=flowed, apply the
> appropriate transformation for display using flow-fill.el.
> ---
> emacs/notmuch-show.el | 3 ++-
> emacs/notmuch-wash.el | 14 ++
> 2 files c
David Bremner writes:
> How is the performance of tree-view on these threads?
tree-view? Loading is about equally slow with/without
notmuch-show-indent-messages-width=0. Navigation is pretty fast once
loaded. "notmuch show --format=sexp" for an 1100 message thread with
7.5 MB of non-attachmen
David Bremner writes:
> How is the performance of tree-view on these threads?
tree-view? Loading is about equally slow with/without
notmuch-show-indent-messages-width=0. Navigation is pretty fast once
loaded. "notmuch show --format=sexp" for an 1100 message thread with
7.5 MB of non-attachmen
Michael Hudson-Doyle writes:
> I have encountered this too. A C-u before entering the thread helps
> (this means already read messages are not rendered I think), as does a
> M-x notmuch-show-toggle-thread-indentation .
Thanks, Michael. This does help, though it makes it hard to interpret
con
Michael Hudson-Doyle writes:
> I have encountered this too. A C-u before entering the thread helps
> (this means already read messages are not rendered I think), as does a
> M-x notmuch-show-toggle-thread-indentation .
Thanks, Michael. This does help, though it makes it hard to interpret
con
I occasionally end up with threads containing several hundred messages
and deep nesting. Eventually, displaying them exceeds the default
max-specpdl-size and later max-lisp-eval-depth. These variables can be
increased, but the time required to display the thread stretches to
minutes. Does anyone
I occasionally end up with threads containing several hundred messages
and deep nesting. Eventually, displaying them exceeds the default
max-specpdl-size and later max-lisp-eval-depth. These variables can be
increased, but the time required to display the thread stretches to
minutes. Does anyone
Searching by Message-Id no longer works via the old mail-archive.com
API, though I have contacted them in hopes that they restore it to
prevent dead links. Anyway, the new API is cleaner.
Acked-by: Austin Clements
---
Fixed the test. Thanks, David.
emacs/notmuch-show.el | 2 +-
test/T310-emac
Searching by Message-Id no longer works via the old mail-archive.com
API, though I have contacted them in hopes that they restore it to
prevent dead links. Anyway, the new API is cleaner.
Acked-by: Austin Clements
---
Fixed the test. Thanks, David.
emacs/notmuch-show.el | 2 +-
test/T310-emac
Searching by Message-Id no longer works via the old mail-archive.com
API, though I have contacted them in hopes that they restore it to
prevent dead links. Anyway, the new API is cleaner.
---
emacs/notmuch-show.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/emacs/notmuch-s
Searching by Message-Id no longer works via the old mail-archive.com
API, though I have contacted them in hopes that they restore it to
prevent dead links. Anyway, the new API is cleaner.
---
emacs/notmuch-show.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/emacs/notmuch-s
Tomi Ollila writes:
> %.o: %.cc $(global_deps)
> - @mkdir -p .deps/$(@D)
> + @mkdir -p $(patsubst %/.,%,.deps/$(@D))
> $(call quiet,CXX $(CPPFLAGS) $(CXXFLAGS)) -c $(FINAL_CXXFLAGS) $< -o $@
> -MD -MP -MF .deps/$*.d
An alternative approach is to use directory marker files [1] to
Tomi Ollila writes:
> %.o: %.cc $(global_deps)
> - @mkdir -p .deps/$(@D)
> + @mkdir -p $(patsubst %/.,%,.deps/$(@D))
> $(call quiet,CXX $(CPPFLAGS) $(CXXFLAGS)) -c $(FINAL_CXXFLAGS) $< -o $@
> -MD -MP -MF .deps/$*.d
An alternative approach is to use directory marker files [1] to
My laptop had a kernel oops this morning, apparently triggered by
getting bumped (not very hard, actually). Upon restarting, I have a
corrupt database:
$ notmuch search tag:inbox
My laptop had a kernel oops this morning, apparently triggered by
getting bumped (not very hard, actually). Upon restarting, I have a
corrupt database:
$ notmuch search tag:inbox
Justus Winter <4winter at informatik.uni-hamburg.de> writes:
> But why do we do that? I always thought that rpath causes more
> problems and is to be avoided if possible [0]. But otoh, I didn't even
> knew that the notmuch build system uses rpath.
>
> 0: e.g. http://wiki.debian.org/RpathIssue
RPAT
Justus Winter <4winter at informatik.uni-hamburg.de> writes:
>
> May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
> to a non-standard location as unprivileged user and to make this
> library available I add its path to LD_LIBRARY_PATH.
See libdir_in_ldconfig testing in confi
Justus Winter <4win...@informatik.uni-hamburg.de> writes:
> But why do we do that? I always thought that rpath causes more
> problems and is to be avoided if possible [0]. But otoh, I didn't even
> knew that the notmuch build system uses rpath.
>
> 0: e.g. http://wiki.debian.org/RpathIssue
RPATH i
Justus Winter <4win...@informatik.uni-hamburg.de> writes:
>
> May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch
> to a non-standard location as unprivileged user and to make this
> library available I add its path to LD_LIBRARY_PATH.
See libdir_in_ldconfig testing in configur
If libnotmuch.so is installed to a path that is not searched by
dlopen(3), we must import it using an absolute path because the Python
bindings do not have the luxury of RPATH linking. So strip off the
trailing directories from the install location and try CDLL with an
absolute path.
---
This is s
David Bremner writes:
> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to
> do it myself.
I tested the attached and it's working as expected. Sent as an
attachment to preserve author information.
-- next part --
A non-text attachment was scrubbed.
If libnotmuch.so is installed to a path that is not searched by
dlopen(3), we must import it using an absolute path because the Python
bindings do not have the luxury of RPATH linking. So strip off the
trailing directories from the install location and try CDLL with an
absolute path.
---
This is s
David Bremner writes:
> Squashed sounds good to me too. Sorry I'm too lazy/busy at the moment to
> do it myself.
I tested the attached and it's working as expected. Sent as an
attachment to preserve author information.
>From 5404ac5bf13f8b5349d5b94f9f2000e9d1832b83 Mon Sep 17 00:00:00 2001
Fro
On Sat, Jul 2, 2011 at 07:44, David Bremner wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
> ?freeze
> --.-.- master
> ? \ ? ? ? ? ? /
> ? ?---
> ? ? ? ? ? ? ? release
>
> As long as every patch on the re
On Sat, Jul 2, 2011 at 07:44, David Bremner wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
> freeze
> --.-.- master
> \ /
> ---
> release
>
> As long as every patch on the re
On Tue, 23 Nov 2010 16:41:40 +0100, Michal Sojka wrote:
> On Mon, 22 Nov 2010, Xavier Maillard wrote:
> M-x cd ~/src/notmuch
> | git am
An arguable refinement is
| (cd ~/src/notmuch; git am -3)
> Then I manually switch to *notmuch-pipe* buffer to see whether the
> command failed or not. It
On Tue, 23 Nov 2010 16:41:40 +0100, Michal Sojka wrote:
> On Mon, 22 Nov 2010, Xavier Maillard wrote:
> M-x cd ~/src/notmuch
> | git am
An arguable refinement is
| (cd ~/src/notmuch; git am -3)
> Then I manually switch to *notmuch-pipe* buffer to see whether the
> command failed or not. It
This permits saved searches like "today".
---
This is similar functionality to David's patch, but uses an accessor so that
queries are always evaluated dynamically.
emacs/notmuch-hello.el |4 ++--
emacs/notmuch-lib.el | 11 ++-
emacs/notmuch.el |2 +-
3 files changed, 1
This permits saved searches like "today".
---
This is similar functionality to David's patch, but uses an accessor so that
queries are always evaluated dynamically.
emacs/notmuch-hello.el |4 ++--
emacs/notmuch-lib.el | 11 ++-
emacs/notmuch.el |2 +-
3 files changed, 1
On Fri, Oct 29, 2010 at 18:17, Felipe Contreras
wrote:
>
> Well, it's not possible: pkg-config is supposed to work on win32 and
> osx, so all the dependencies must be there, so:
>
> % pkg-config --libs gmime-2.6
> -pthread -lgmime-2.6 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0
> -lgthread-2.0 -lrt -lgl
On Fri, Oct 29, 2010 at 18:17, Felipe Contreras
wrote:
>
> Well, it's not possible: pkg-config is supposed to work on win32 and
> osx, so all the dependencies must be there, so:
>
> % pkg-config --libs gmime-2.6
> -pthread -lgmime-2.6 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0
> -lgthread-2.0 -lrt -lgl
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
wrote:
> As long as all the repos are synced, then you only need to track one.
> But notmuch already has "official" repos [0], and making another
> pseudo-"official" repo will probably just makes things more confusing.
Patches show up in a different
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
wrote:
> As long as all the repos are synced, then you only need to track one.
> But notmuch already has "official" repos [0], and making another
> pseudo-"official" repo will probably just makes things more confusing.
Patches show up in a different
On Tue, 02 Mar 2010 16:26:10 +0100, Paul R wrote:
> CouchDB databases can be replicated and synced in both directions.
> Conflicts are lazily handled.
I've wondered about this. An interesting property would be lack of a
global lock, which is one of the reasons why people are either not
having no
On Tue, 02 Mar 2010 16:26:10 +0100, Paul R wrote:
> CouchDB databases can be replicated and synced in both directions.
> Conflicts are lazily handled.
I've wondered about this. An interesting property would be lack of a
global lock, which is one of the reasons why people are either not
having no
On Tue, 09 Feb 2010 11:19:54 -0800, Carl Worth wrote:
> I did verify the above in a copy of WG14/N1124. For anyone that doesn't
> recognize that, that's the draft from the C99 working group that I've
> been told is remarkably similar to C99 but distinct in that it's freely
> available[*]. I haven'
On Tue, 09 Feb 2010 11:19:54 -0800, Carl Worth wrote:
> I did verify the above in a copy of WG14/N1124. For anyone that doesn't
> recognize that, that's the draft from the C99 working group that I've
> been told is remarkably similar to C99 but distinct in that it's freely
> available[*]. I haven'
On Mon, 08 Feb 2010 12:24:06 -0500, Jameson Rollins wrote:
> I don't think that this is exactly correct. The quoting is interpreted
> by the shell in order to construct a single string that is then passed
> as an argument to the program.
The command line distinguishes, but the constructed query
On Mon, 08 Feb 2010 12:24:06 -0500, Jameson Rollins
wrote:
> I don't think that this is exactly correct. The quoting is interpreted
> by the shell in order to construct a single string that is then passed
> as an argument to the program.
The command line distinguishes, but the constructed query
On Thu, 04 Feb 2010 12:54:20 -0800, Carl Worth wrote:
> And I'm glad I did because that turned up a bug in the patch, (using
> == instead of != for the return value of strcasestr resulted in *all*
> messages with a Reply-To header being considered as munged).
Yikes, I've been using this thing for
On Thu, 04 Feb 2010 12:54:20 -0800, Carl Worth wrote:
> And I'm glad I did because that turned up a bug in the patch, (using
> == instead of != for the return value of strcasestr resulted in *all*
> messages with a Reply-To header being considered as munged).
Yikes, I've been using this thing for
On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari wrote:
> Sounds like you need to add a line to crontab.
I haven't been following this thread closely so I hope this isn't too
out of context. I agree that certain things like notmuch-new should go
in the crontab, but I think that notmuch-new should
On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari wrote:
> Sounds like you need to add a line to crontab.
I haven't been following this thread closely so I hope this isn't too
out of context. I agree that certain things like notmuch-new should go
in the crontab, but I think that notmuch-new should
On Fri, 15 Jan 2010 09:59:54 -0400, David Bremner wrote:
> Is this over/under engineered? I spent roughly as long on the design as
> it took me to type :). Maybe the whole session id thing is redundant and
> could be done at the socket level. Or, getting more serious about the
> whole thing, mayb
Looks like this was just a bug in Xapian HEAD, today's build works just
fine and I'm enjoying the faster CHERT backend. Bulk tagging is really
loads faster now, and the interactivity is better than before, but SPC
still has a noticeable pause (at least 200 ms) since (apparently) it's
doing an fsyn
On Fri, 15 Jan 2010 09:59:54 -0400, David Bremner wrote:
> Is this over/under engineered? I spent roughly as long on the design as
> it took me to type :). Maybe the whole session id thing is redundant and
> could be done at the socket level. Or, getting more serious about the
> whole thing, mayb
Looks like this was just a bug in Xapian HEAD, today's build works just
fine and I'm enjoying the faster CHERT backend. Bulk tagging is really
loads faster now, and the interactivity is better than before, but SPC
still has a noticeable pause (at least 200 ms) since (apparently) it's
doing an fsyn
I rebuilt notmuch and got a Xapian exception while notmuch new was
upgrading my database. This seemed like a decent time to try the latest
Xapian, so I built a copy and the crash remained (and maintainer-mode
still optimizes so I built Xapian again so I could get decent
debugging). Here is a trac
I rebuilt notmuch and got a Xapian exception while notmuch new was
upgrading my database. This seemed like a decent time to try the latest
Xapian, so I built a copy and the crash remained (and maintainer-mode
still optimizes so I built Xapian again so I could get decent
debugging). Here is a trac
On Sat, 19 Dec 2009 15:41:14 +1100, Alex Ghitza wrote:
> Bcc-ing myself on every sent message is suboptimal for a number of
> reasons: (1) gmail throws away the bcc-ed copy since it has the same
> message id as the one sitting in the gmail sent mail, and so the
> bcc-ed copy never makes it back to
On Sat, 19 Dec 2009 15:41:14 +1100, Alex Ghitza wrote:
> Bcc-ing myself on every sent message is suboptimal for a number of
> reasons: (1) gmail throws away the bcc-ed copy since it has the same
> message id as the one sitting in the gmail sent mail, and so the
> bcc-ed copy never makes it back to
On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth wrote:
> 1. Rewriting the code to not use apply-partially
1b. Use apply-partially
(defun apply-partially (fun &rest args)
"Return a function that is a partial application of FUN to ARGS.
ARGS is a list of the first N arguments to pass to FUN.
The
On Wed, 09 Dec 2009 12:00:21 -0800, Carl Worth wrote:
> 1. Rewriting the code to not use apply-partially
1b. Use apply-partially
(defun apply-partially (fun &rest args)
"Return a function that is a partial application of FUN to ARGS.
ARGS is a list of the first N arguments to pass to FUN.
The
On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth wrote:
> But surely there's a way to implement this with dramatically less code
> duplication?
It should just be very short after this series
id:1259450376-24523-1-git-send-email-jed at 59A2.org
I think --format= should not be used for this, for
On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth wrote:
> But surely there's a way to implement this with dramatically less code
> duplication?
It should just be very short after this series
id:1259450376-24523-1-git-send-email-...@59a2.org
I think --format= should not be used for this, format
I know html support is still poor, but the following seems worse than
not showing anything. When I visit this message, I get prompted to save
the MIME part and the following is displayed (including all the hidden
stuff). Original message is attached.
Jed
message{ id:4B182A91.9020304 at sandia
I know html support is still poor, but the following seems worse than
not showing anything. When I visit this message, I get prompted to save
the MIME part and the following is displayed (including all the hidden
stuff). Original message is attached.
Jed
message{ id:4b182a91.9020...@sandia.go
Jan, thanks for looking into this.
On Wed, 2 Dec 2009 15:38:54 +0100, Jan Janak wrote:
> This seems close enough to what you want and maybe we could somehow make it
> work with notmuch, too. This would be interesting to have, because then we
> could complete multiple tag names with a single TAB p
On Wed, 2 Dec 2009 14:18:08 +0100, Jan Janak wrote:
> I haven't been really following this thread in detail. What is that you need
> from notmuch-select-tag-with-completion? To be able to process a list of tags
> separated by spaces? Maybe I could help you with that.
No, it would need to take inp
notmuch-search-filter now accepts an arbitrary query and will group if
necessary so that we get
tag:inbox AND (gravy OR biscuits)
instead of the former
tag:inbox AND gravy OR biscuits
Signed-off-by: Jed Brown
---
notmuch.el |5 -
1 files changed, 4 insertions(+), 1 deletions
A patch for notmuch-search-filter follows, my change to
notmuch-search-filter-by-tag is not very useful since
notmuch-select-tag-with-completion does not allow a space to be
inserted. I don't know how to get completion on multiple
space-separated terms.
On Tue, 01 Dec 2009 18:56:59 -0800, Carl Wo
Jan, thanks for looking into this.
On Wed, 2 Dec 2009 15:38:54 +0100, Jan Janak wrote:
> This seems close enough to what you want and maybe we could somehow make it
> work with notmuch, too. This would be interesting to have, because then we
> could complete multiple tag names with a single TAB p
On Wed, 2 Dec 2009 14:18:08 +0100, Jan Janak wrote:
> I haven't been really following this thread in detail. What is that you need
> from notmuch-select-tag-with-completion? To be able to process a list of tags
> separated by spaces? Maybe I could help you with that.
No, it would need to take inp
notmuch-search-filter now accepts an arbitrary query and will group if
necessary so that we get
tag:inbox AND (gravy OR biscuits)
instead of the former
tag:inbox AND gravy OR biscuits
Signed-off-by: Jed Brown
---
notmuch.el |5 -
1 files changed, 4 insertions(+), 1 deletions
A patch for notmuch-search-filter follows, my change to
notmuch-search-filter-by-tag is not very useful since
notmuch-select-tag-with-completion does not allow a space to be
inserted. I don't know how to get completion on multiple
space-separated terms.
On Tue, 01 Dec 2009 18:56:59 -0800, Carl Wo
On Tue, 1 Dec 2009 10:33:05 +0100, Steen Manniche wrote:
> Probably unusable system info:
> % uname -a
> Linux algorithm 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST
> 2009 i686 Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz GenuineIntel
> GNU/Linux
This is pretty much my fault because I made
On Tue, 1 Dec 2009 10:33:05 +0100, Steen Manniche wrote:
> Probably unusable system info:
> % uname -a
> Linux algorithm 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST
> 2009 i686 Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz GenuineIntel
> GNU/Linux
This is pretty much my fault because I made
This avoids erroneously calling internet_address_list_length() with a
NULL list (which was causing a gmime exception).
Signed-off-by: Jed Brown
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 9b9e9ab..6c9118e
This avoids erroneously calling internet_address_list_length() with a
NULL list (which was causing a gmime exception).
Signed-off-by: Jed Brown
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 9b9e9ab..6c9118e
users list
Signed-off-by: Jed Brown
---
notmuch-reply.c | 47 ++-
1 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index b91a830..9b9e9ab 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -182
add_recipients_from_message, in order to isolate more sophisticated
mailing list logic.
Signed-off-by: Jed Brown
---
notmuch-reply.c | 88 ---
1 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
The former one worked in 23.1.50.1 but not in 23.1.1.
Signed-off-by: Jed Brown
---
notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 96c5d96..65473ba 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1152,7 +1152,7 @@ characters as
On Sat, 28 Nov 2009 09:55:43 -0800, Carl Worth wrote:
> On Sat, 28 Nov 2009 17:05:06 +0100, Jed Brown wrote:
> > Handling this is a bit messy, I think we want the current behavior
> > unless To matches Reply-To, in which case we use From and Reply-To. If
> > this is
Signed-off-by: Jed Brown
---
notmuch.1 | 22 +++---
notmuch.c | 16 ++--
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/notmuch.1 b/notmuch.1
index 2be77f9..04bd0cf 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -211,9 +211,9 @@ section below for
First, I'm aware that such munging is A Bad Thing
http://www.unicom.com/pw/reply-to-harmful.html
but a lot of lists do it anyway (mostly to work around widely used
mailers with lame defaults). After munging, we get headers looking like
this
From: Some User
To: Sample users list
Reply-
users list
Signed-off-by: Jed Brown
---
notmuch-reply.c | 47 ++-
1 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index b91a830..9b9e9ab 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -182
add_recipients_from_message, in order to isolate more sophisticated
mailing list logic.
Signed-off-by: Jed Brown
---
notmuch-reply.c | 88 ---
1 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
On Fri, 27 Nov 2009 21:54:11 -0800, Carl Worth wrote:
> Ah. So we have our first case of emacs-lisp portability issues.
Bummer, my docs say nothing about this changing, let alone in a way
that's going to break anything that used it.
> I'm using "GNU emacs 23.1.1" currently, for what it's worth.
The former one worked in 23.1.50.1 but not in 23.1.1.
Signed-off-by: Jed Brown
---
notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 96c5d96..65473ba 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1152,7 +1152,7 @@ characters as
On Sat, 28 Nov 2009 09:55:43 -0800, Carl Worth wrote:
> On Sat, 28 Nov 2009 17:05:06 +0100, Jed Brown wrote:
> > Handling this is a bit messy, I think we want the current behavior
> > unless To matches Reply-To, in which case we use From and Reply-To. If
> > this is
Signed-off-by: Jed Brown
---
notmuch.1 | 22 +++---
notmuch.c | 16 ++--
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/notmuch.1 b/notmuch.1
index 2be77f9..04bd0cf 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -211,9 +211,9 @@ section below for
First, I'm aware that such munging is A Bad Thing
http://www.unicom.com/pw/reply-to-harmful.html
but a lot of lists do it anyway (mostly to work around widely used
mailers with lame defaults). After munging, we get headers looking like
this
From: Some User
To: Sample users list
Reply-
On Fri, 27 Nov 2009 21:54:11 -0800, Carl Worth wrote:
> Ah. So we have our first case of emacs-lisp portability issues.
Bummer, my docs say nothing about this changing, let alone in a way
that's going to break anything that used it.
> I'm using "GNU emacs 23.1.1" currently, for what it's worth.
On Fri, 27 Nov 2009 06:02:45 -0800, Carl Worth wrote:
> Since this operates via a single call to "notmuch tag" you might mention
> here that all tag removals occur before any tag additions.
I was unaware of this point, if I do
notmuch tag -inbox +star tag:inbox some-expression
I will have sta
On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth wrote:
> Thanks for the patch, Jed, I almost pushed it, but noticed that it's
> calling `called-interactively-p' with an argument even though that
> function does not accept an argument.
My docs say it does take an argument:
called-interactively-p
On Fri, 27 Nov 2009 06:02:45 -0800, Carl Worth wrote:
> Since this operates via a single call to "notmuch tag" you might mention
> here that all tag removals occur before any tag additions.
I was unaware of this point, if I do
notmuch tag -inbox +star tag:inbox some-expression
I will have sta
On Fri, 27 Nov 2009 05:41:44 -0800, Carl Worth wrote:
> Thanks for the patch, Jed, I almost pushed it, but noticed that it's
> calling `called-interactively-p' with an argument even though that
> function does not accept an argument.
My docs say it does take an argument:
called-interactively-p
function is primarily used when browsing an inbox).
Signed-off-by: Jed Brown
---
notmuch.el |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 6adac9e..e9786c0 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -935,15 +935,19 @@ and will also
It is often convenient to change tags on several messages at once. This
function applies any number of tag whitespace-delimited tag
modifications to all messages matching the current query.
I have bound this to `*'.
Signed-off-by: Jed Brown
---
notmuch.el | 24 ++
On Thu, 26 Nov 2009 13:14:22 -0800, Carl Worth wrote:
> Then I'm still being really dense here. The non-propagation of mtime is
> the with actual directories. And the code is trying to do the right
> thing for that.
The stat() is correct, it's the check for the d_type field coming out of
scandi
On Thu, 26 Nov 2009 10:34:12 -0800, Carl Worth wrote:
> I'm a little confused here. Notmuch only uses stat, so it should be
> looking at the target's mtime already. It actually takes special effort
> (via lstat) to get at the mtime of the link itself.
>
> So why aren't things just working?
Becau
function is primarily used when browsing an inbox).
Signed-off-by: Jed Brown
---
notmuch.el |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 6adac9e..e9786c0 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -935,15 +935,19 @@ and will also
It is often convenient to change tags on several messages at once. This
function applies any number of tag whitespace-delimited tag
modifications to all messages matching the current query.
I have bound this to `*'.
Signed-off-by: Jed Brown
---
notmuch.el | 24 ++
On Thu, 26 Nov 2009 13:14:22 -0800, Carl Worth wrote:
> Then I'm still being really dense here. The non-propagation of mtime is
> the with actual directories. And the code is trying to do the right
> thing for that.
The stat() is correct, it's the check for the d_type field coming out of
scandi
On Thu, 26 Nov 2009 10:34:12 -0800, Carl Worth wrote:
> I'm a little confused here. Notmuch only uses stat, so it should be
> looking at the target's mtime already. It actually takes special effort
> (via lstat) to get at the mtime of the link itself.
>
> So why aren't things just working?
Becau
This currently means the same thing as --format=headers-only, but this
name gives more freedom to change --format=headers-only without breaking
existing versions of git.
---
notmuch-reply.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
Apparently this is actually the correct way to do it, it's silly to do
it wrong just to conform to one of git's internal data structures.
---
notmuch-reply.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index e85568c..9ca1236
This command only generates References, To, and Cc headers.
The purpose is primarily for use in
git send-email --notmuch id:
to get proper threading and address the relevant parties. Hooks for
other SCMs may come later.
Signed-off-by: Jed Brown
---
notmuch-reply.c | 70
This factors actual generation of the reply out of notmuch_reply_command
into notmuch_reply_format_default(), in preparation for other --format=
options.
Signed-off-by: Jed Brown
---
notmuch-reply.c | 121 +++---
1 files changed, 78 insertions
1 - 100 of 133 matches
Mail list logo
