From: Austin Clements
Previously, the test assumed the generated message would be assigned a
specific thread ID; now it doesn't. Also, spelling fix.
Signed-off-by: Jameson Graef Rollins
---
test/search-output |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a
eturns the From header value
of the forwarded email.
Message-field-value is the same as message-fetch-field, only
narrows the buffer to the headers first.
Signed-off-by: Jameson Graef Rollins
---
emacs/notmuch-maildir-fcc.el |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
di
The declaration of the GMimeStream pointer to stdout in
format_part_content_text was somehow preventing subsequent printf
calls from outputting to stdout if the output was redirected to a
file. Scoping the declaration to the actual use of the stream pointer
works around this problem.
---
notmuch-
This is a much cleaner way to do the emacs tests, since we're actually
comparing output against existing files with expected output. We also
won't miss any trailing newlines this way.
And speaking of which, one of the expected output files was actually
missing a trailing blank line that was actua
Again, this is a much cleaner and more thorough test, and in fact
exposes a bug in the format=text output, that will be fixed the next
commit. Because of this, some of the multipart tests currently fail.
---
test/multipart | 189
1 files c
On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins
wrote:
> So what follows is a patch series for a bunch of miscellaneous patches
> that should be included in 0.6. Most of them were originally part of
> the release-candiate/0.6 branch, and they are here rebased on top of
This function, like the equivalent for notmuch-search, just refreshes
the current show view. Like in notmuch-search, this new function is
bound to "=". If a prefix is given then the rediplay happens with the
crypto-switch set, which displays the thread with the opposite logic
of whatever is set i
Use prefix argument instead to set switch.
---
emacs/notmuch.el |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 3311fe8..0978c66 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -218,7 +218,6 @@ For a mouse binding, re
The main reason to introduce this new unexposed function is to allow
the buffer redisplay crypto switch to behaving in a more expected way.
The prefix to notmuch-show-redisplay buffer now switches the crypto
processing of the current show buffer, as opposed to switching the
logic of the notmuch-cry
---
emacs/notmuch-show.el |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 3b35b81..6e0d454 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -805,7 +805,11 @@ non-nil.
The optional BUFFER-NAME provid
On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel wrote:
> CC -O2 notmuch-reply.o
> notmuch-reply.c: In function ‘notmuch_reply_command’:
> notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
> notmuch-reply.c:659:3: warning: passing argument 1 of
> ‘g_mime_gpg_context_new’ from incompa
On Mon, 30 May 2011 21:30:03 +0200, Felix Geller wrote:
> Most of the test cases in crypto fail as well, but I'm not sure which
> ones are actually supposed to work.
Hey, Felix. As David said, all crypto tests should be passing with
libgmime 2.4.24. It would probably be instructive to know whic
This mentions the fact that prefix arguments are now used to enable to
crypto switch.
---
emacs/notmuch-crypto.el |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index 096dc5e..44fccae 100644
--- a/emacs/notmuch-crypto.
This adds two callback functions to the sigstatus button. If the sig
status is "good", then clicking the button displays the output of "gpg
--list-keys" on the key fingerprint. If the sigstatus is "bad", then
clicking the button will retrieve the key from the keyserver, and
redisplay the current
Hi, folks. I have pushed a new version of the release-candidate/0.6
branch to my repo [0]. It is all reworked on top of notmuch/master [1],
and includes:
* the miscellaneous fixes/improvements patch series starting at
id:"1306619520-25730-2-git-send-email-jroll...@finestructure.net"
* the notm
On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel wrote:
> This used to work and used to be supported and was broken in a recent
> notmuch patch.
Hey, Dirk. I would actually say that support for gmime 2.6 was merely
coincidental up until now. For all functionality we had been using, the
API in 2
On Wed, 01 Jun 2011 16:22:19 -0700, Carl Worth wrote:
> Thanks for the patch. I was intrigued about what was actually broken
> here, so tracked down the problem and fixed it with an alternate patch
> (see below).
Cool. Yeah, that issue took a while to track down.
jamie.
pgpWidel4eYpy.pgp
Desc
On Tue, 31 May 2011 19:33:29 +0200, Felix Geller wrote:
> I get the following trace when using show --decrypt to decrypt a
> specific message (have to kill the process to actually get the trace):
>
> #0 0x0001006121a6 in poll ()
> #1 0x00010006d3d2 in gpg_ctx_op_step ()
> #2 0x0001
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but cer
After the recent part-handling overhaul, emacs handling of
message/rfc822 parts broke, not outputting the message contents. This
"fixes" then handling as is, but there are still problems with how
notmuch is outputting message parts that needs to be addressed (for
instance, message headers are not
Hey, folks. I've been noticing a couple of issues with message/rfc822
part handling in recent builds of notmuch/master. They are rooted in
the new part handling rework that was done recently. I just want to
mention them here, to make people aware of them, until we get a chance
to address them.
On Thu, 02 Jun 2011 18:49:22 +0200, Felix Geller wrote:
> Jeff replied and sent me a working patch :) Not sure yet how he prefers
> to publish the patch, but the problem is fixed.
That's great! What did Jeff say exactly? Is the patch to gmime 2.4?
Did he mention that he was including them in up
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but cer
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth wrote:
> On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
> wrote:
> > The declaration of the GMimeStream pointer to stdout in
> > format_part_content_text was somehow preventing subsequent printf
> > calls from out
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth wrote:
> Otherwise, the patches up to this point in the thread have all either
> been pushed or I've asked for some additional information (perhaps
> that's just this patch and the "old style fcc dirs" patch?).
Great! That's really great news, Carl.
On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth wrote:
> commit d5b4d950245605b84c56ce991fa3c59a073a70e5
> Author: Jameson Graef Rollins
> Date: Sat May 28 14:52:00 2011 -0700
>
> show: Avoid inadvertently closing stdout
>
> GMime has a nasty habit of taking
This new function takes a GMimeMessage as input, and outputs the
formatted headers. This allows for message/rfc822 parts to be
formatted on output in a similar way to full messages (see previous
patch that overhauls the multipart test for more info).
---
notmuch-client.h |1 +
notmuch-reply.c
The insert-part-message/rfc822 function is overhauled to properly
processes the new formatting of message/rfc822 parts. The json output
for message parts now includes "headers" and "body" fields, which are
now parsed and output appropriately.
---
emacs/notmuch-show.el | 21 +
The test message date, "Tue, 05 Jan 2001 15:43:57 -", is not
actually a real date. 05 Jan 2001 was in fact a Friday, not a
Tuesday. Date parsers (such as "date" in coreutils) will return "Fri"
as the day for this string, even if "Tue" is specified.
Also, the time zone "-" is actually alw
So the following patch series is my attempt to improve handling of
message/rfc822 parts. The first couple of patches fix/overhaul the
multipart test, and the last two improve the message/rfc822 part
output and emacs handling, respectively.
The fix outputs the rfc822 message in a format similar to
There were two "--format=text --part=0" tests. One of them was
supposed to be a test for "--format=text --part=1".
There were also two errant "test_expect_equal_file OUTPUT EXPECTED"
lines, that are removed here.
---
test/multipart | 17 ++---
1 files changed, 2 insertions(+), 15 d
The main goal of this overhaul is to define how message/rfc822 parts
should be handled. message/rfc822 parts should be output in a similar
fashion to the outer message, including some subset of the rfc822
headers. The following decisions about formatting of message/rfc822
parts were made:
The fo
I forgot to mention that this patch series (well the last patch in
particular) supersedes the previous emacs rfc822 part handling patch I
sent in:
id:"1307034386-6107-1-git-send-email-jroll...@finestructure.net"
jamie.
pgpMyp64jKP3K.pgp
Description: PGP signature
___
On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
>
> emacs: update notmuch-crypto-process-mime c
Here's the gmime bug about returning rfc822 messages as GMimeObjects:
https://bugzilla.gnome.org/show_bug.cgi?id=651964
jamie.
pgpqPmrMDqcxr.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)
I've been thinking about this more and it really seems we need a
On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth wrote:
> Frankly, I wouldn't mind doing strict time-based releases with something
> like the following:
Hi, Carl. I think this is a fine idea, and we (not you) can definitely
run this process. I'm quite sure that at least bremner and I can
complete
On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes to
The quoted text doesn't need to mention that the message being replied
to had these crufty parts.
---
notmuch-reply.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7a76ba3..0eb295e 100644
--- a/notmuch-reply.c
+++ b/notmuch-rep
These lines are just cruft in this case, and can be removed.
---
notmuch-reply.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index a19eb19..7a76ba3 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -93,7 +93,12 @@ reply_p
There's no reason to output "Non-text part:" lines for parts that are
not leaf nodes, eg. multipart/* and message/rfc822. We fix the text
here to test for their absence. The next patch will fix reply
accordingly.
---
test/multipart |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
di
This is a small set of tweaks to remove unneccessary "Non-text part:"
lines in reply, for parts that really don't need to be mentioned.
This patch set is not really related to the series that it is being
sent in reply to, but it has been worked on top of the message/rfc822
rework of the multipart
In reply, the quoted text does not need to mention that the original
message had "application/pgp-signed" or "application/pgp-encrypted"
parts.
---
test/crypto|2 --
test/multipart |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/test/crypto b/test/crypto
index 8e92
On Tue, 14 Jun 2011 21:58:48 +0530, "Aneesh Kumar K.V"
wrote:
> Lars Kellogg-Stedman - 2009-11-17
> |-> Mikhail Gusarov - 2009-11-17
> |-> Lars Kellogg-Stedman - 2009-11-17
> |->"Mikhail Gusarov" - 2009-11-17
> |->"Keith Packard" - 2009-11-17
Or better yet:
┬╴ Lars Kell
On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins
wrote:
> This adds two callback functions to the sigstatus button. If the sig
> status is "good", then clicking the button displays the output of "gpg
> --list-keys" on the key fingerprint. If the sigstatus
On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin
wrote:
> I know you prefer tests to go before patches and I agree with that. But
> most of the time I do tests after coding. I do not know an easy way to
> reorder patches in git. (Also I do not know how to amend an old patch,
> wish more da
Maintainer: Carl Worth
Uploaders: Jameson Graef Rollins , martin f.
krafft
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs (>= 23~),
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet wrote:
> recently, using the head of notmuch-git:
>
> git://notmuchmail.org/git/notmuch
>
> when a mail ends with an url and is recognized as a signature:
...
> I can't hit [space] to go to the next thread and I get the following
> error:
> E
On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet wrote:
> it is only when the signature is lumped like below, that I get the error:
> [ 4-line signature. Click/Enter to show. ]
>
> also, it's only happening to the last message of a thread.
Ah, ok. Have you tried looking at the raw mess
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
>
> Attachment:
> 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
> (application/octet-stream)
Are you sure this is the right
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
>
Attachment:
1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
(application/octet-stream)
Hi, Sebastien. I don't seem to have
On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet wrote:
> and I checked there were no lingering .el files...
>
> so...
> any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> when comes to hacking lisp)
Hey, Sebastien. You can determine the loaded version of a librar
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
libz-dev,
emacs23 | emacs23-nox,
python-all (>= 2.6.6-3~),
-St
:
- martin f. krafft ,
+ martin f. krafft ,
Jameson Graef Rollins ,
David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ p
-Uploaders: martin f. krafft ,
- Jameson Graef Rollins ,
- David Bremner
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
pyt
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
libgmime-2.4-dev,
libtalloc-dev,
libz-dev,
- emacs23-nox,
+ em
hrm, sorry. Looks like those last two patches got a little messed up.
These two patches replace the previous two.
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
-Uploaders: martin f. krafft ,
- Jameson Graef Rollins ,
- David Bremner
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
pyt
---
debian/control | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
martin f. krafft ,
Jameson Graef Rollins ,
David Bremner
I think we just agreed with cworth on irc that this simple patch will
satisfy his regression worry for 0.6. Meaning that we can push out
the release after this patch is merged.
bremner, our new "Release Tyrant", has his finger on the trigger...
___
not
This is patch is a temporary work-around for a slight regression that
popped up in the part handling reorganization. Currently, text/plain
parts are always preferred, if present, over other non-text/plain
parts in multipart/alternative. However, this means that if there is
a blank text/plain part
On Thu, 23 Jun 2011 09:13:05 +0200, Sebastian Spaeth
wrote:
> Me bows to the tyrant and the hard-working henchmen. :)
We (henchmen) generally prefer to go by the official title of
Interim Distinguished co-Chief Vice Tyrant.
jamie.
pgp6gQsY9ndfp.pgp
Description: PGP signature
_
Hey, folks. As of today I am for some reason no longer able to build
the Notmuch Debian package. I'm using the same build technique I have
been using for a while (git-buildpackage). The tail of the failing
build log is pasted at the bottom of this message. Is anyone else
encountering anything l
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green wrote:
> A race condition in the '*' command was noted when it was first
> proposed. It looks to me like it still exists - has anything been done
> about it?
Hi, Robin. Can you explain what you mean by the "'*' command"? Are you
referring to '*' a
On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote:
> I'd like to investigate this case a little bit to help answer the
> question of whether "notmuch should have done anything in this case".
Hi, Carl. You can see this error if you try to output raw a multipart/*
or message/rfc822 part, ie:
s
On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner wrote:
> 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
>and July 1.
Hi, David. You might want to consider applying the following patches
for 0.6:
Bug fix for raw output of gmime parts:
id:"1307120466-4980-1-g
On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements wrote:
> Just to clarify my understanding, --format=raw is only intended to
> work on either the whole message (special-cased in do_show_single) or
> a leaf MIME part, and in any other case, it will output nothing? The
> raw output test cases se
This test was not properly documented when it was originally added (my
bad).
---
test/README |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/test/README b/test/README
index 8fbf78d..f9ac607 100644
--- a/test/README
+++ b/test/README
@@ -156,6 +156,13 @@ library for y
On Tue, 28 Jun 2011 07:31:31 +, Jani Nikula wrote:
> Add a pseudo saved search that matches all the mail that no other saved
> search matches. Add new customization option notmuch-saved-searches-nomatch
> to enable and name the pseudo saved search.
Hi, Jani. I haven't looked too closely at t
On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green wrote:
> It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> thread which has multiple unread replies! Yes, the other unread replies
> will still be tagged unread, but the user might not immediately be aware
> of them. It would be
On Wed, 29 Jun 2011 20:15:22 +, Jani Nikula wrote:
> So to clarify, do you prefer having on/off switches, or just enabling
> this without customization at all? Personally I'd shy away from the
> latter, but I guess it depends on how useful vs. distracting people find
> this.
My opinion is to
On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson wrote:
> I personally prefer --output=files remain as it was, with one file per
> mail (even though I submitted the patch to change it). I suggest that
> we could add another format to supply all files (perhaps
> --output=allfiles, or --output=dup
On Thu, 30 Jun 2011 13:04:23 +1000, Brian May
wrote:
> Are there any keyboard bindings to go forwards to the next message or
> backwards to the last message without marking anything as archived?
'n' and 'p'. These are documented in the notmuch-show mode help ('?'
while in notmuch-show mode).
j
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle
wrote:
> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote:
> Non-text part: multipart/mixed
> Non-text part: multipart/signed
>
> not sure why notmuch reply is putting that there :)
They shouldn't be, and I sent a patch to fix that a
On Fri, 1 Jul 2011 13:13:27 -0700 (PDT),
notmuch-commits-sen...@notmuchmail.org (David Bremner) wrote:
> The annotated tag, 0.6 has been created
> at 6eae40d57f12bb44d1b375a1d37454974f6dafd2 (tag)
>tagging 6bd02fb4dbee9e0fc372661af573a2ac380fed8a (commit)
> replaces 0.6rc1
> tag
On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre wrote:
> I like to use the space (and sometimes the backspace key) to read
> threads back and forth, but sometimes I might read stuff to quickly and
> archive a thread without wanting it. It is then complex to find it back
> (especially if the t
Hey, folks. Now that 0.6 is *finally* out the door, it's time to start
working on 0.7. As Interim Distinguished co-Chief Vice Tyrant I have
been tasked with starting the discussion on 0.7 release priorities.
Below is just the beginning of list of things that have been discussed
on the list that
On Thu, 07 Jul 2011 20:49:35 +0200, Matthieu Lemerre wrote:
> On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements wrote:
> > * Make SPC mark the *current* message read and move to the next one,
> > rather than moving to the next and marking it read. This way, you're
> > acknowledging the message
On Thu, 7 Jul 2011 16:58:08 -0400, Austin Clements wrote:
> What I'm suggesting is no more or less automatic than the current
> behavior. It's just a slight tweak to the order in which things
> happen: that SPC could remove the unread tag and then move to the next
> message, rather than the other
On Fri, 24 Jun 2011 16:34:02 -0700, Jameson Graef Rollins
wrote:
> What could be preventing dpkg-shlibdeps from finding libpthread.so.0
> or libc.so.6?
Hey, folks. For the curious, I was able to resolve this issue with some
help from the dpkg-dev maintainers [0]. It turns out that I w
On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller wrote:
> I added a variable to toggle message indentation in Emacs.
Hi, Felix. Thanks for submitting this patch. I think it's a good idea.
I have a couple of comments below, a couple of which echo what Dmitry
has already pointed out.
> diff --gi
On Thu, 14 Jul 2011 23:22:58 +0100, Patrick Totzke
wrote:
> I wodered why "notmuch search --format=json" doesn't provide the
> "date_relative" field for
> results, as the show command does.
>
> I'm not expert on notmuch internals but I got it working like this:
Hi, Patrick. I think this is a
On Wed, 13 Jul 2011 01:46:24 +0200, Felix Geller wrote:
> Ok, tried again :)
Hey, Felix. It looks like the two attachments to your email are
actually the emails generated by format-patch that should have been sent
to the list. Instead of attaching them to other emails, send them to
the list di
On Fri, 15 Jul 2011 22:04:59 +0100, Patrick Totzke
wrote:
> Thanks for the tip with git send-mail.
Hi, Patrick. You might have noticed my response to Felix a little while
ago. The git format-patch command outputs an email that is meant to be
sent directly to the list, not as an attachment on a
Hi, Felix. Thanks for resubmitting these patches. A couple more
comments:
Remember to include a longer log message with you patch. Beyond just
the single line commit message, the patch should also include a longer
commit message, separated from the first line by a blank line, that
explains what
On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza wrote:
> I just inadvertently removed the "todo" tag from all my "todo"-tagged
> emails (about 60 of them going back several months, so I doubt I can
> find them all again in my email haystack). So I have a few questions:
Hey, Alex. This won't hel
On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin
wrote:
> On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost wrote:
> > Before this change, the test suite reported many failed tests on machines
> > where
> > screen is not installed (which is the case of many *BSD systems). This patch
> > makes
On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander
wrote:
> I wonder if it may be possible to create a journal of all the operations
> on tags: a file where all the changes are registered, with a timestamp.
>
> Two benefits:
> - going through the history to undo mistakes
> - being able to b
On Wed, 20 Jul 2011 17:36:43 -0400, Antoine Beaupré wrote:
> I think this is a great idea. Unfortunately, I had a lot of trouble
> making message-mode digest an existing buffer. For example, if you take
> any existing buffer and call (message-mode) on it, you will notice it
> will clear the buffer
On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins
wrote:
> Being also to share tags alone would be super cool.
I have no idea what this means, but I do know that tag sharing would be
super cool, and I think time stamping tag operations could help
facilitate it.
ja
On Thu, 21 Jul 2011 23:32:58 +0200, Xavier Maillard wrote:
> Maybe I misunderstood original goal but what I had in mind reading this
> is certainly not editing a priviously received message in order to
> (re)send it again but sending a postponed/draft message which, I guess,
> means no full header
On Thu, 21 Jul 2011 20:00:45 -0400, Antoine Beaupré wrote:
> How about we patch that in? Seems like a major feature missing...
Handling postponed messages is definitely something that's missing.
It's a little tricky, though, because notmuch-show.el doesn't handle
display of message-mode formatted
On Sun, 24 Jul 2011 00:32:39 -0400, Aaron Ecay wrote:
> According to the Glib docs
> (http://developer.gnome.org/gobject/unstable/gobject-Type-Information.html#g-type-init),
> the g_type_init() function must be called before using any GType
> stuff, which notmuch_filter_discard_uuencode_new does.
On Mon, 25 Jul 2011 16:33:09 -0400, Aaron Ecay wrote:
> Signed-off-by: Aaron Ecay
Hey, Aaron. Thanks for submitting this patch. However, you will need
to provide a more detailed log message in order for it to be pulled by
Carl. The commit message should explain what exactly the problem is,
an
Hey, Aaron. This patch looks good. Thanks for resubmitting it.
So you say that this only sometimes yields a crash. Do you know of any
way to trigger it? I wonder why it causes a crash sometimes and not
others.
jamie.
pgpMKxLjd6UJs.pgp
Description: PGP signature
_
On Wed, 3 Aug 2011 16:47:32 -0400, Austin Clements wrote:
> The patch I posted above includes message ID's in search results as a
> proxy for the match set (which can then be used in a tagging operation
> to tag exactly the results you saw). However, from an efficiency
> standpoint, it makes more
On Fri, 05 Aug 2011 17:17:56 +0200, Daniel Schoepe
wrote:
> On Mon, 06 Jun 2011 18:32:41 +0200, Daniel Schoepe
> wrote:
> I've been using this patch for the past two months now and it has been
> working fine. Are there any more suggestions or criticisms about this?
Hey, Daniel. This is a real
From: Daniel Schoepe
This patch adds completion with in the minibuffer for
notmuch-search and notmuch-search-filter.
---
This is a slightly tweaked version of this original patch that removes
an errant space and uses "search --output=tags" instead of the
deprecated "search-tags".
emacs/notmuch
Hey, Daniel. I actually just ran into a little bug with this patch.
After applying this patch, if I try to scroll/search through my
mini-buffer history after a search I get the following error:
previous-history-element: Wrong type argument: symbolp, "tag:signed"
I get this error no matter what m
On Tue, 09 Aug 2011 19:31:44 +0200, Daniel Schoepe
wrote:
> Turns out, I just used `read-from-minibuffer' incorrectly, here's an
> updated version.
Hey, Daniel. Thanks so much for the quick fix! This new patch seems to
work great.
Signed-off-by: Jameson Graef
601 - 700 of 1816 matches
Mail list logo
