On Fri, 02 Dec 2011 09:20:35 -0500, James Westby <jw+debian at jameswestby.net>
wrote:
> I'll test again to make sure that I have this correct, but my tests
> yesterday certainly suggested that your patches fixed this.
Yep, segfaults a plenty dropping your second patch that go awa
On Fri, 02 Dec 2011 13:35:11 +0100, Justus Winter <4winter at
informatik.uni-hamburg.de> wrote:
> Huh, strange. My patch isn't supposed to change anything, it just
> enables the ctypes package to check whether the functions from
> libnotmuch are called with the right parameters, thus preventing
>
On Fri, 02 Dec 2011 13:35:11 +0100, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
Huh, strange. My patch isn't supposed to change anything, it just
enables the ctypes package to check whether the functions from
libnotmuch are called with the right parameters, thus preventing
mistakes
On Fri, 02 Dec 2011 09:20:35 -0500, James Westby jw+deb...@jameswestby.net
wrote:
I'll test again to make sure that I have this correct, but my tests
yesterday certainly suggested that your patches fixed this.
Yep, segfaults a plenty dropping your second patch that go away again
when
From: James Westby <james.wes...@linaro.org>
ctypes doesn't return c_void_p return values as that, it returns them as
32-bit integers instead. This has two problems:
1 - On 64-bit machines anything higher than the max 32-bit integer
will overflow when passed back in to another fu
Hi,
I've been seeing a race with python-notmuch, where it will crash due to
pointers being invalidated when threads are used.
I've attached a script which shows the problem some of the time. It's
about the smallest script I can make, but it's hampered by the fact that
making it simpler seems to
Hi,
I've been seeing a race with python-notmuch, where it will crash due to
pointers being invalidated when threads are used.
I've attached a script which shows the problem some of the time. It's
about the smallest script I can make, but it's hampered by the fact that
making it simpler seems to
On Thu, 1 Dec 2011 18:13:05 -0500, James Westby jw+deb...@jameswestby.net
wrote:
From: James Westby james.wes...@linaro.org
ctypes doesn't return c_void_p return values as that, it returns them as
32-bit integers instead. This has two problems:
1 - On 64-bit machines anything higher
On Thu, 01 Dec 2011 22:25:41 +0100, Sebastian Spaeth sebast...@sspaeth.de
wrote:
This strikes me as a rather good thing, so the patches went in.
Hah, I've just seen this, and I'm going to guess that it fixes my
problems too.
...
I've tested and it seems to work, so my patch is unneeded witht
On Wed, 14 Apr 2010 00:43:16 +0200, Xavier Maillard wrote:
> Is it done automatically ? Or do I need to do something special
> in order to unset the unread tag ?
>
> I see there is 'a' and 'x' when in notmuch-show but I am not sure
> I have to explicitely press on of these keys.
>
> Currently,
On Tue, 13 Apr 2010 19:29:29 -0400, Jameson Rollins wrote:
> On Tue, 13 Apr 2010 23:19:37 +0100, James Westby <jw+debian at
> jameswestby.net> wrote:
> > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote:
> > > Say I have a thread with A-B-C. I visit the thre
On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote:
> Hi,
>
> maybe I missread the "manual" but I can't find an easy way to do
> something simple in notmuch.el.
>
> Say I have a thread with A-B-C. I visit the thread and read the
> whole thread. Let's say after 'notmuch new' a post has
On Tue, 13 Apr 2010 08:20:48 -0700, Carl Worth wrote:
> Thanks for this patch, James! It's especially nice to have the fix come
> in with additions to the test suite as well.
Thanks for including a test suite I could add to!
> I did split up the commit so the addition to the test suite happens
On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard x...@gnu.org wrote:
Hi,
maybe I missread the manual but I can't find an easy way to do
something simple in notmuch.el.
Say I have a thread with A-B-C. I visit the thread and read the
whole thread. Let's say after 'notmuch new' a post has
On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth wrote:
> * Anything else that people want, (especially things that already
> exist and that you're already using). Support for maildir flags on
> import would be great here. I'm still waiting to see a complete
> solution I think.
On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
* Anything else that people want, (especially things that already
exist and that you're already using). Support for maildir flags on
import would be great here. I'm still waiting to see a complete
solution I
On Sun, 14 Mar 2010 19:19:11 +0100, Michal Sojka wrote:
> Mails with empty body produced the following output:
> "body": [{"id": 1, "content-type": "text/plain", "content": (null)}]
> The (null) is not valid JSON syntax.
Is this just something that can happen with the body?
I've see (null) in
This allows us to thread messages even when we receive them out of
order, or never receive the root.
The thread ids for messages that aren't present but are referred to are
stored as metadata in the database and then retrieved if we ever get
that message.
When determining the thread id for a
This allows us to thread messages even when we receive them out of
order, or never receive the root.
The thread ids for messages that aren't present but are referred to are
stored as metadata in the database and then retrieved if we ever get
that message.
When determining the thread id for a
On Tue, 2 Mar 2010 16:43:10 +0100, martin f krafft
wrote:
> also sprach Paul R [2010.03.02.1626 +0100]:
> > CouchDB databases can be replicated and synced in both directions.
> > Conflicts are lazily handled.
>
> What does this mean?
Couch has deterministic conflict resolution between the two
On Tue, 2 Mar 2010 16:43:10 +0100, martin f krafft madd...@madduck.net wrote:
also sprach Paul R paul.r...@gmail.com [2010.03.02.1626 +0100]:
CouchDB databases can be replicated and synced in both directions.
Conflicts are lazily handled.
What does this mean?
Couch has deterministic
On Fri, 26 Feb 2010 12:08:49 -0800, Carl Worth wrote:
> It seems clear that I'll have some opportunities to present notmuch to
> various audiences at varying levels of formality. Since notmuch is
> already a bigger project than me, I'd love to get some ideas from others
> about what you think are
On Fri, 19 Feb 2010 08:32:42 +, David Edmondson wrote:
> How about this:
Looks reasonable to me, thanks.
James
Some people send html parts as text/HTML or similar, so do a
case-sensitive comparison when checking for html parts.
---
notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 0f4ea10..b69c334 100644
--- a/notmuch.el
+++ b/notmuch.el
@@
Some people send html parts as text/HTML or similar, so do a
case-sensitive comparison when checking for html parts.
---
notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 0f4ea10..b69c334 100644
--- a/notmuch.el
+++ b/notmuch.el
@@
On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft
wrote:
> also sprach Jameson Rollins [2010.01.27.0603
> +1300]:
> > > This is getting involved.
> > >
> > > Maybe I'm missing something in this thread; but, why couldn't these
> > > complex and
> > > context-sensitive decisions be
On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft madd...@madduck.net wrote:
also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603
+1300]:
This is getting involved.
Maybe I'm missing something in this thread; but, why couldn't these
complex and
On Thu, 28 Jan 2010 18:34:21 +1300, martin f krafft madd...@madduck.net wrote:
also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]:
Are you trying to use thread: such that it could be passed to
notmuch show to see the conversation?
That's not going to work so well
On Fri, 8 Jan 2010 15:56:10 +1300, martin f krafft
wrote:
> also sprach Jameson Graef Rollins
> [2009.11.26.1901 +1300]:
> > I would really like to start using notmuch with emacs beyond just
> > testing, but I really need to be able to handle/read/send mail with
> > PGP/MIME encoded
When scanning the maildir there can be earlier messages
in the thread that we haven't seen, either due to mail
delays, or because they weren't sent. This can break the
threading.
Therefore we store stub documents for every message id
we see, so that we can link them in to the threads. If
we see
From: Tomas Carnecky <t...@dbservice.com>
Use stat(2) instead.
Signed-off-by: Tomas Carnecky
Signed-off-by: James Westby <jw+debian at jameswestby.net>
---
The original patch duplicated asprintf and stat calls, rearraging
the code means we don't need to.
I have a c
When scanning the maildir there can be earlier messages
in the thread that we haven't seen, either due to mail
delays, or because they weren't sent. This can break the
threading.
Therefore we store stub documents for every message id
we see, so that we can link them in to the threads. If
we see
---
lib/message.cc |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cc32741..7129d59 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -391,7 +391,7 @@ notmuch_message_get_replies (notmuch_message_t *message)
* multiple
On Fri, 18 Dec 2009 16:57:16 -0800, Carl Worth wrote:
> You can, actually. Just set the NOTMUCH_CONFIG environment variable to
> your alternate configuration file. (And yes, we're missing any mention
> of this in our documentation.)
Sweet. Where would be the best place to document it? Just in
When we see a message where we already have the file
id stored, check if the size is larger. If it is then
re-index and set the file size and name to be the
new message.
---
Here's the (quite simple) patch to implement indexing the
largest copy of each mail that we have.
Does the
When indexing a message store the filesize along with it so that
when we store all the filenames for a message-id we can know if
any of them have different content cheaply.
The value stored is defined to be the largest filesize of any
of the files for that message.
This changes the API for
On Fri, 18 Dec 2009 14:29:21 -0800, Carl Worth wrote:
> On Fri, 18 Dec 2009 21:21:03 +0000, James Westby <jw+debian at
> jameswestby.net> wrote:
> Yes, a value makes sense here and should make the value easy to
> retrieve.
Excellent.
> I usually use a little tool I wro
On Fri, 18 Dec 2009 12:52:58 -0800, Carl Worth wrote:
> On Fri, 18 Dec 2009 19:53:13 +0000, James Westby <jw+debian at
> jameswestby.net> wrote:
> Oh, I was assuming you wouldn't index any text. The UI can add "missing
> message" for a document with no filename
When indexing a message store the filesize along with it so that
when we store all the filenames for a message-id we can know if
any of them have different content cheaply.
The value stored is defined to be the largest filesize of any
of the files for that message.
This changes the API for
On Fri, 18 Dec 2009 11:41:18 -0800, Carl Worth wrote:
> On Fri, 18 Dec 2009 19:02:21 +0000, James Westby <jw+debian at
> jameswestby.net> wrote:
> > Therefore I'd like to fix this. The obvious way is to
> > introduce documents in to the db for each id we see,
When indexing a message store the filesize along with it so that
when we store all the filenames for a message-id we can know if
any of them have different content cheaply.
The value stored is defined to be the largest filesize of any
of the files for that message.
This changes the API for
On Fri, 18 Dec 2009 12:52:58 -0800, Carl Worth cwo...@cworth.org wrote:
On Fri, 18 Dec 2009 19:53:13 +, James Westby jw+deb...@jameswestby.net
wrote:
Oh, I was assuming you wouldn't index any text. The UI can add missing
message for a document with no filename, for example.
Works for me
When we see a message where we already have the file
id stored, check if the size is larger. If it is then
re-index and set the file size and name to be the
new message.
---
Here's the (quite simple) patch to implement indexing the
largest copy of each mail that we have.
Does the
On Fri, 18 Dec 2009 16:57:16 -0800, Carl Worth cwo...@cworth.org wrote:
You can, actually. Just set the NOTMUCH_CONFIG environment variable to
your alternate configuration file. (And yes, we're missing any mention
of this in our documentation.)
Sweet. Where would be the best place to document
---
lib/message.cc |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cc32741..7129d59 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -391,7 +391,7 @@ notmuch_message_get_replies (notmuch_message_t *message)
* multiple
45 matches
Mail list logo
