On Wed, 22 Jun 2011 18:14:12 -0700, Jameson Graef Rollins wrote:
>
> One way to get around this is to set the
> "notmuch-show-all-multipart/alternative-parts" customization variable
> to True ('t'), which will cause all parts to always be displayed.
>
Pushed.
;http://notmuchmail.org/pipermail/notmuch/attachments/20110622/9633d22a/attachment.pgp>
On Wed, 22 Jun 2011 18:14:12 -0700, Jameson Graef Rollins
wrote:
>
> One way to get around this is to set the
> "notmuch-show-all-multipart/alternative-parts" customization variable
> to True ('t'), which will cause all parts to always be displayed.
>
Pushed.
__
No, it's not a code name, unless you really want it to be. After some
discussion with Carl and Jamie on IRC, I have declared myself release
tyrant, with Jamie as my assistant [1].
The release plan is as follows.
1) Create a release branch (called release) at b0ba84f9e71b0.
You can get this br
On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins
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 brem
se what makes notmuch fun is that it helps me more
quickly eliminate so much of the annoyance of email from my life so that
I can focus more on the things that I really want to.
--
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110622/fe0ecb45/attachment.pgp>
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
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
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...
Ping.
On Sat, Jun 11, 2011 at 4:04 PM, Austin Clements wrote:
> Here's the reworked patch series that uses atomic sections more
> heavily rather than changing the removal API. ?This is atomic-new-v6
> on http://awakening.csail.mit.edu/git/notmuch.git .
>
> (I was planning to make this series on M
Ping.
On Sat, Jun 11, 2011 at 4:04 PM, Austin Clements wrote:
> Here's the reworked patch series that uses atomic sections more
> heavily rather than changing the removal API. This is atomic-new-v6
> on http://awakening.csail.mit.edu/git/notmuch.git .
>
> (I was planning to make this series on M
From: David Bremner
The worry here is that a binary linking with libnotmuch might lose
access to Xapian::Error symbols because libnotmuch hides them.
---
test/basic |2 +-
test/notmuch-test |1 +
test/symbol-hiding | 21 +
test/symbol-test.cc | 17
about this. I don't have a problem with either way.
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110622/509f54ec/attachment.pgp>
cation/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110622/b98ce35d/attachment.pgp>
On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth
wrote:
> I see your point. I was approached with this by someone very
> confused that tagging via notmuch binary would automatically move mails
> between cur/new folders while tagging via python would do nothing of
> this sort.
That's also a g
name.
What do you think?
-Carl
--
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110622/6eba85f3/attachment.pgp>
On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet wrote:
> On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth wrote:
> > Perhaps this is an emacs bug?
> could be, but,
>
> > I'm using Debian's emacs 23.3.1 and have not encountered the problem
> > described.
> I don't see anything related to 'point
On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet
wrote:
> On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth wrote:
> > Perhaps this is an emacs bug?
> could be, but,
>
> > I'm using Debian's emacs 23.3.1 and have not encountered the problem
> > described.
> I don't see anything related to 'poin
From: David Bremner
The worry here is that a binary linking with libnotmuch might lose
access to Xapian::Error symbols because libnotmuch hides them.
---
test/basic |2 +-
test/notmuch-test |1 +
test/symbol-hiding | 21 +
test/symbol-test.cc | 17
20 matches
Mail list logo
