This allows for testing against both versions of gmime on a single
machine, without having to mess with pkg-config paths.
---
configure |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 8b85b9d..630d647 100755
--- a/configure
+++ b/configu
On Thu, 8 Mar 2012 10:38:32 -0700, Jeremy Nickurak wrote:
> On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor
> wrote:
> > Any other suggestions or ideas?
>
> What about representing the contents from both message in one apparent
> message?
> - ...
> - If the bodies disagree, display both.
We
This allows for testing against both versions of gmime on a single
machine, without having to mess with pkg-config paths.
---
configure |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 8b85b9d..630d647 100755
--- a/configure
+++ b/configu
On Thu, 8 Mar 2012 10:38:32 -0700, Jeremy Nickurak
wrote:
> On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor
> wrote:
> > Any other suggestions or ideas?
>
> What about representing the contents from both message in one apparent
> message?
> - ...
> - If the bodies disagree, display both.
W
On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner wrote:
> I have sometimes wondered about having another library layer making some
> of the current CLI functionality accessible to bindings. I'm not really
> sure of the pro's and con's of such approach. It would certainly be
> overkill for this on
On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner wrote:
> I have sometimes wondered about having another library layer making some
> of the current CLI functionality accessible to bindings. I'm not really
> sure of the pro's and con's of such approach. It would certainly be
> overkill for this on
On Fri, 24 Feb 2012 23:36:23 +, Mark Walters
wrote:
> I have played with this and I like the feel of it: it is much more
> informative than completing-read and much less cluttered than
> ido-completing-read.
I wonder if the completion method should be customizable, rather than
forcing a par
On Fri, 24 Feb 2012 23:36:23 +, Mark Walters
wrote:
> I have played with this and I like the feel of it: it is much more
> informative than completing-read and much less cluttered than
> ido-completing-read.
I wonder if the completion method should be customizable, rather than
forcing a par
On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost
wrote:
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> fails (signature verification with signer key unavailable) but this will be
> hard
On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost wrote:
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test
> fails (signature verification with signer key unavailable) but this will be
> hard
>
On Wed, 21 Dec 2011 23:06:50 +0100, Thomas Jost
wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Tue, 20 Dec 2011 15:20:04 +, David Edmondson wrote:
> > Cast away the result of various *write functions. Provide a default
> > value for some variables to avoid "use be
On Wed, 21 Dec 2011 23:06:50 +0100, Thomas Jost wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Tue, 20 Dec 2011 15:20:04 +, David Edmondson wrote:
> > Cast away the result of various *write functions. Provide a default
> > value for some variables to avoid "use bef
On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements wrote:
> This protocol requires significantly more state, but can also
> reconstruct per-tag changes. Conflict resolution is equivalent to
> what git would do and is based solely on the current local and remote
> state and the common ancestor st
On Sun, 18 Dec 2011 19:59:28 +0100, Krzysztof Ilowiecki
wrote:
> I understand synchronisation across machines and with IMAP is something
> of an issue so far. How bad would it be to use git for that - and for
> 'undo'? It would appear some people use git+maildir even instead of
> IMAP, but I gues
On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner wrote:
> The more worrying part is disk usage; the tag tree for 200k messages
> uses 400k inodes, and 836M of apparent disk usage (according to du) the
> same tags in "sup" format take 11M. Maybe this could be usefull if
> combined with some schem
On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements wrote:
> This protocol requires significantly more state, but can also
> reconstruct per-tag changes. Conflict resolution is equivalent to
> what git would do and is based solely on the current local and remote
> state and the common ancestor st
On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner wrote:
> The more worrying part is disk usage; the tag tree for 200k messages
> uses 400k inodes, and 836M of apparent disk usage (according to du) the
> same tags in "sup" format take 11M. Maybe this could be usefull if
> combined with some schem
On Sun, 18 Dec 2011 19:59:28 +0100, Krzysztof Ilowiecki
wrote:
> I understand synchronisation across machines and with IMAP is something
> of an issue so far. How bad would it be to use git for that - and for
> 'undo'? It would appear some people use git+maildir even instead of
> IMAP, but I gues
On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner wrote:
> On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins finestructure.net> wrote:
>
> > Hey, David. What exactly is the problem here? These seems like it's
> > actually reasonable behavior when you're using emacs in daemon mode,
> >
On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner wrote:
> On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins
> wrote:
>
> > Hey, David. What exactly is the problem here? These seems like it's
> > actually reasonable behavior when you're using emacs in daemon mode,
> > yes? I don't ac
On Thu, 15 Dec 2011 08:14:08 -0400, David Bremner wrote:
> On Mon, 4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin
> wrote:
> > Result: nothing happens except for "No URL at point" message
> >
> > Expected result: the second message is shown/hidden
>
> Unfortunately this patch is unreliable, repo
On Thu, 15 Dec 2011 08:14:08 -0400, David Bremner wrote:
> On Mon, 4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin gmail.com> wrote:
> > Result: nothing happens except for "No URL at point" message
> >
> > Expected result: the second message is shown/hidden
>
> Unfortunately this patch is unreliab
On Wed, 07 Dec 2011 19:51:32 -0400, David Bremner wrote:
> I could see idea of excluding spam and trash folders from indexing being
> useful, but this has been sitting in the list for a few months without
> comment. Does that mean no-one but Tomi thinks the functionality is
> interesting? Or it ju
On Wed, 07 Dec 2011 19:51:32 -0400, David Bremner wrote:
> I could see idea of excluding spam and trash folders from indexing being
> useful, but this has been sitting in the list for a few months without
> comment. Does that mean no-one but Tomi thinks the functionality is
> interesting? Or it ju
On Tue, 06 Dec 2011 18:47:01 -0800, Jameson Graef Rollins wrote:
> Also, what if we make it so that the post-new hook script only runs if
> notmuch new processes new messages? All of my post-new functions don't
> need to be run at all if there is no new mail.
Or would it make sense to pass this
On Tue, 06 Dec 2011 18:47:01 -0800, Jameson Graef Rollins
wrote:
> Also, what if we make it so that the post-new hook script only runs if
> notmuch new processes new messages? All of my post-new functions don't
> need to be run at all if there is no new mail.
Or would it make sense to pass this
On Sun, 04 Dec 2011 21:36:21 +0200, Jani Nikula wrote:
> > > +if (run_hooks && !ret && !interrupted)
> > > + ret = notmuch_run_hook (db_path, "post-new");
> >
> > Does it matter at this point if the hook fails? I'm not sure.
>
> I wasn't sure either, but I ended up thinking that the hooks b
On Sun, 04 Dec 2011 21:36:21 +0200, Jani Nikula wrote:
> > > +if (run_hooks && !ret && !interrupted)
> > > + ret = notmuch_run_hook (db_path, "post-new");
> >
> > Does it matter at this point if the hook fails? I'm not sure.
>
> I wasn't sure either, but I ended up thinking that the hooks b
On Sun, 4 Dec 2011 01:16:49 +0200, Jani Nikula wrote:
> Run notmuch new pre and post hooks, named "pre-new" and "post-new", if
> present in the notmuch hooks directory. The hooks will be run before and
> after incorporating new messages to the database.
>
> Typical use cases for pre-new and post
On Sun, 4 Dec 2011 01:16:49 +0200, Jani Nikula wrote:
> Run notmuch new pre and post hooks, named "pre-new" and "post-new", if
> present in the notmuch hooks directory. The hooks will be run before and
> after incorporating new messages to the database.
>
> Typical use cases for pre-new and post
From: Thomas Schwinge
Asking xapian to sort the messages for us causes suboptimal IO patterns. This
would be useful, if we only wanted the first few results, but since we want
everything anyway, this is pessimization.
On 2011-10-29, a measurement on a 372981 messages instance showed that wall
ti
From: Thomas Schwinge
Asking xapian to sort the messages for us causes suboptimal IO patterns. This
would be useful, if we only wanted the first few results, but since we want
everything anyway, this is pessimization.
On 2011-10-29, a measurement on a 372981 messages instance showed that wall
ti
Perhaps the g++ step in symbol-hiding should in fact be a test. Right
now, that step failing isn't captured by the test-suite.
Tom
glibc includes a libutil, so if the wrong -L options get passed, we
will pick up glibc's version, rather than our own.
---
lib/Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Makefile.local b/lib/Makefile.local
index cb53781..54c4dea 100644
--- a/lib/Ma
For some reason, on my machine, the link is picking up
/usr/lib/libutil.so instead of util/libutil.a. This causes there to be
undefined symbols in libnotmuch, making it unuseable. This patch causes
the link to fail instead.
---
lib/Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 dele
Perhaps the g++ step in symbol-hiding should in fact be a test. Right
now, that step failing isn't captured by the test-suite.
Tom
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
glibc includes a libutil, so if the wrong -L options get passed, we
will pick up glibc's version, rather than our own.
---
lib/Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Makefile.local b/lib/Makefile.local
index cb53781..54c4dea 100644
--- a/lib/Ma
For some reason, on my machine, the link is picking up
/usr/lib/libutil.so instead of util/libutil.a. This causes there to be
undefined symbols in libnotmuch, making it unuseable. This patch causes
the link to fail instead.
---
lib/Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 dele
On Thu, 06 Oct 2011 21:53:57 -0300, David Bremner wrote:
> On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin gmail.com> wrote:
> > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote:
>
> > IMHO 1[+2] is the way. It breaks the dump command interface, but would
> > make it consistent wit
On Thu, 06 Oct 2011 21:53:57 -0300, David Bremner wrote:
> On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin
> wrote:
> > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote:
>
> > IMHO 1[+2] is the way. It breaks the dump command interface, but would
> > make it consistent with other
I know that having an exclude option for notmuch has been discussed a
number of times. I have wanted such a feature to be able to ignore the
.git directroy, since I keep my mail in a git repository. I recently
discovered a workaround.
If you make .git a text file containing
= .git
gitdir:
I know that having an exclude option for notmuch has been discussed a
number of times. I have wanted such a feature to be able to ignore the
.git directroy, since I keep my mail in a git repository. I recently
discovered a workaround.
If you make .git a text file containing
= .git
gitdir:
On Fri, 30 Sep 2011 12:43:53 +0200, Justus Winter <4winter at
informatik.uni-hamburg.de> wrote:
> while iterating over a query result set my process died with
>
> > terminate called after throwing an instance of
> > 'Xapian::DatabaseModifiedError'
> > Aborted
>
> I am not sure where this came f
On Fri, 30 Sep 2011 12:43:53 +0200, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> while iterating over a query result set my process died with
>
> > terminate called after throwing an instance of
> > 'Xapian::DatabaseModifiedError'
> > Aborted
>
> I am not sure where this came from
On Tue, 23 Aug 2011 20:11:53 -0400, James Vasile
wrote:
> No known mail client or fetch tool stores mail in dot files, because
> files that start with '.' are usually used to store metadata
> (i.e. state or configuration) as opposed to subject-matter data.
Dovecot stores folders in directories s
On Tue, 23 Aug 2011 20:11:53 -0400, James Vasile
wrote:
> No known mail client or fetch tool stores mail in dot files, because
> files that start with '.' are usually used to store metadata
> (i.e. state or configuration) as opposed to subject-matter data.
Dovecot stores folders in directories s
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote:
> This has the advantage that "git describe master" starts to count from
> 0.6 instead of 0.5. Currently e.g. "make dist" on master is making
> notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
> "increasingly innacurately named"
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote:
> This has the advantage that "git describe master" starts to count from
> 0.6 instead of 0.5. Currently e.g. "make dist" on master is making
> notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
> "increasingly innacurately named"
On 2011-04-17, Pieter Praet wrote:
> On Sat, 16 Apr 2011 15:23:44 -0400, Tom Prince
> wrote:
> > > > Further, for certain mails I sent (like this one ) I would like a
> > > > WAITING tag (or similar) in order to indicate that I am waiting for an
> > >
On 2011-04-17, Pieter Praet wrote:
> On Sat, 16 Apr 2011 15:23:44 -0400, Tom Prince
> wrote:
> > > > Further, for certain mails I sent (like this one ) I would like a
> > > > WAITING tag (or similar) in order to indicate that I am waiting for an
> > >
> > Further, for certain mails I sent (like this one ) I would like a
> > WAITING tag (or similar) in order to indicate that I am waiting for an
> > answer. Currently I set this manually. Could this be achieved through
> > some indicators via message mode or similar means? e.g.:
> >
> > <#notmuch
> > Further, for certain mails I sent (like this one ) I would like a
> > WAITING tag (or similar) in order to indicate that I am waiting for an
> > answer. Currently I set this manually. Could this be achieved through
> > some indicators via message mode or similar means? e.g.:
> >
> > <#notmuch
On 2011-01-23, Michal Sojka wrote:
> Hi all,
>
> the following patch series brings into notmuch date/time parser stolen
> from GNU coreutils. It can be applied on top of custom query parser
> patches from Austin Clements.
>
> This is RFC and it not meant for merging.
Another source for date pars
On 2011-01-23, Michal Sojka wrote:
> Hi all,
>
> the following patch series brings into notmuch date/time parser stolen
> from GNU coreutils. It can be applied on top of custom query parser
> patches from Austin Clements.
>
> This is RFC and it not meant for merging.
Another source for date pars
54 matches
Mail list logo