[PATCH] emacs: Show all multipart/alternative parts by default.

[David Bremner]

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.

Notmuch 0.6: Let's do it.

[David Bremner]

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 branch now from the main notmuch repo. 

2) Add id:"1308791652-17372-2-git-send-email-jrollins at finestructure.net"
   or equivalent 

3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
   and July 1.

4) Release July 1.

The next release will approximately August 1, with a feature freeze
around July 23.  Normally this might be a lousy time for a release, but
some of us will be hacking in Banja Luka the week before.

David

[1] In the traditional manner, Jamie has done most of the work, and I am
swooping in at the last minute to steal credit ;).

[2] If you have to ask who decides what is _important_, you haven't
understood the release tyrant concept completely.



-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110622/9633d22a/attachment.pgp>

When will we have our next release?

[Carl Worth]

 see so many good people working
hard and having fun to collectively make such a fun tool![*]

> If we can just grease the wheels a little bit to get releases out the
> door a little quicker, I think we'll all be a lot happier.

Hopefully, we're doing that. Thanks for all your efforts, Jamie. I
really appreciate them. And I'm happier at least!

-Carl

[*] For "fun tool" I always have to hesitate a bit?notmuch itself is
fun, but it's funny that email itself is often more annoying to me than
anything else. I suppose 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>

[PATCH] emacs: Show all multipart/alternative parts by default.

[Jameson Graef Rollins]

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, no content will be displayed.

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.

Since we want to move forward with the next release, we're going to
set this variable true by default, to make sure that no content is
unretrievably hidden from the user.  Once we come up with a better
solution for easy display of hidden parts we can set this back to a
default value of 'nil'.
---
 emacs/notmuch-show.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0d9b52a..af1d44b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -96,7 +96,7 @@ same as that of the previous message."
 notmuch-wash-excerpt-citations))

 ;; Mostly useful for debugging.
-(defcustom notmuch-show-all-multipart/alternative-parts nil
+(defcustom notmuch-show-all-multipart/alternative-parts t
   "Should all parts of multipart/alternative parts be shown?"
   :group 'notmuch
   :type 'boolean)
-- 
1.7.5.4

I feel a release coming!

[Jameson Graef Rollins]

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...

[PATCH v6 00/17] Fix 'notmuch new' atomicity issues

[Austin Clements]

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 Monday while stuck on a plane,
> but an opportunity presented itself when I needed something better to
> do than fix the sink. ?As a result, if you can look over this before
> Monday, I can use that time to address any further comments.)
>
> The beginning of the sequence---"test: Fix message when skipping
> test_expect_equal* tests" through "new: Defer updating directory
> mtimes until the end."---has not changed besides than the minor things
> you pointed out earlier. ?Here's a quick summary of the differences in
> the rest of the sequence:
>
> lib: Add notmuch_database_{begin,end}_atomic.
> ?Rebased but otherwise identical.
>
> lib: Add support for nested atomic sections.
> ?New.
>
> lib: Indicate if there are more filenames after removal.
> ?Rebased but otherwise identical.
>
> lib: Remove message document directly after removing the last file
> name.
> ?New. ?Supersedes the patches that rewrote
> ?notmuch_database_remove_message and made sync delete messages.
>
> lib: Add an API to find a message by filename.
> ?Culled from "lib: Add API's to find by filename and ..." in the old
> ?series. ?What I kept is identical.
>
> lib: Wrap notmuch_database_add_message in an atomic section.
> ?New.
>
> new: Cleanup. Put removed/renamed message count in add_files_state_t.
> new: Cleanup. De-duplicate file name removal code.
> ?Both new, but closely related to previous remove_filename patch.
>
> new: Synchronize maildir flags eagerly.
> ?New, but very closely related to previous patch of the same name.
> ?This patch is simpler now because of the previous two cleanups.
>
> new: Wrap adding and removing messages in atomic sections.
> ?Rebased and added an atomic section around removal.
>
> lib: Improve notmuch_database_{add,remove}_message documentation.
> ?New.
>
> Ultimately, I still think the existing removal API is weird because it
> forces you to do things like lookup a message by file name just in
> case you need that message object after removal tells you that it
> didn't actually remove the message. ?But I don't know what to do about
> it that isn't equally weird.
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>

[PATCH] tests: add a test for symbol hiding side effects

[da...@tethera.net]

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 +
 4 files changed, 40 insertions(+), 1 deletions(-)
 create mode 100755 test/symbol-hiding
 create mode 100644 test/symbol-test.cc

diff --git a/test/basic b/test/basic
index 808c968..d6e8c10 100755
--- a/test/basic
+++ b/test/basic
@@ -56,7 +56,7 @@ tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
 available=$(ls -1 ../ | \
 sed -r -e 
"/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d" \
   -e 
"/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d" \
-  -e 
"/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d" \
+  -e 
"/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d"
 \
   -e "/^(test.expected-output|.*~)/d" \
   -e "/^(gnupg-secret-key.asc)/d" \
   -e "/^(gnupg-secret-key.NOTE)/d" \
diff --git a/test/notmuch-test b/test/notmuch-test
index 83f284d..fe85c6a 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -40,6 +40,7 @@ TESTS="
   emacs-large-search-buffer
   maildir-sync
   crypto
+  symbol-hiding
 "
 TESTS=${NOTMUCH_TESTS:=$TESTS}

diff --git a/test/symbol-hiding b/test/symbol-hiding
new file mode 100755
index 000..1c1f34e
--- /dev/null
+++ b/test/symbol-hiding
@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2011 David Bremner
+#
+
+test_description='exception symbol test
+
+This test tests whether hiding Xapian::Error symbols in libnotmuch
+also hides them for other users of libxapian. This is motivated by
+the discussion in http://gcc.gnu.org/wiki/Visibility'
+
+. ./test-lib.sh
+
+output="Error opening database at /nonexistant/.notmuch: No such file or 
directory
+caught No chert database found at path \`/nonexistant'"
+
+g++ -o symbol-test ../symbol-test.cc -L../lib -lnotmuch -lxapian
+test_expect_success "$message" ./symbol-test
+test_done
+
+
diff --git a/test/symbol-test.cc b/test/symbol-test.cc
new file mode 100644
index 000..f077845
--- /dev/null
+++ b/test/symbol-test.cc
@@ -0,0 +1,17 @@
+#include 
+#include 
+#include 
+main (int argc, char **argv){
+
+notmuch_database_t *notmuch
+  = notmuch_database_open ("/nonexistant",
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+
+  try{
+(void)new Xapian::WritableDatabase ("/nonexistant",
+   Xapian::DB_OPEN);
+  } catch (const Xapian::Error ) {
+printf("caught %s\n",error.get_msg().c_str());
+  }
+  return 0;
+}
-- 
1.7.5.3

Python updates

[Sebastian Spaeth]

On Tue, 21 Jun 2011 14:46:02 -0700, Carl Worth wrote:
Non-text part: multipart/signed
> On Thu, 16 Jun 2011 15:58:39 +0200, Sebastian Spaeth wrote:
> > Message().maildir_flags_to_tags and tags_to_maildir_flags, which are now
> > by default invoked on Database().add_message and on any operation that
> > modifies notmuch tags. See the updated API docs at:
> 
> I'm not a fan of the above.

Hi Carl,

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.

The automatic tag/flag synchronization can be disabled via a command
line option already now, it is just enabled by default. The behavior is
of course documented in the python API docs. It would be no problem, to
disable the syncing by default to achieve API consistency. (and allow
people to turn it on, if they wish to do so explicitly)

> If we should fix Database().add_message to automatically call
> maildir_flags_to_tags, then we should also fix
> notmuch_database_add_message to do the same thing.


> I can't see any good justification for behavior like this to be
> different depending on the language being used to access the library.

See above, people don't consider using the libnotmuch API, they "tag" a
message via python and it behaves differently than "tag" a message via
notmuch binary
So we'll have some level of inconsistency in any case. :)

> Please consider changing things to match the semantics of the underlying
> library.

Would you be happy to have maildir syncing disabled by default and users
can enable it via a parameter? I do see why you want to achieve
consistency with the API. On the other hand are the python API somewhat
more highlevel than the low-level API calls, and we provide a few
convenience functions that are not available in the API at all.

I can do away with it and force people to invoke the syncing manually,
if you feel strongly 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>

Python updates

[Carl Worth]

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 good point.

But the same confusion can happen to someone using "notmuch tag" and
then switching to using notmuch_message_add_tag at the C library
interface.

That's what I meant when I said that if there's an inconsistency here,
then we should fix it at the C library interface, and not just in a
language-specific wrapper.

> See above, people don't consider using the libnotmuch API, they "tag" a
> message via python and it behaves differently than "tag" a message via
> notmuch binary
> So we'll have some level of inconsistency in any case. :)

Let's figure out one right answer for the library interface, (regardless
of language) and implement that.

> Would you be happy to have maildir syncing disabled by default and users
> can enable it via a parameter?

I'd be happy to hear a proposal to add a parameter to the library
interface for maildir syncing, (and I wouldn't even be opposed to having
it enabled by default).

The only thing I care about strongly here is that we have a single
library interface. I don't want one interface in C, a different
interface in python, (and different interfaces in go, ruby, etc.).

Sometimes a language will provide some convenient builtin handling for
something that's awkward at the notmuch C interface, (such as a native
interface for iterators). And I definitely don't mind a language binding
using something like that as opposed to manually binding every
iteration-supporting function that we have in the notmuch library.

But I don't want to see semantic changes to the interface that don't
have anything to do with the language itself.

> I do see why you want to achieve consistency with the API.

Thanks.

> On the other hand are the python API somewhat more highlevel than the
> low-level API calls, and we provide a few convenience functions that
> are not available in the API at all.

That's not the stance I'd like to see.

If you want convenience in the python interface that doesn't exist in
the C interface, then let's start by fixing the C interface.

If there's convenience you want in the python interface that shouldn't
exist in the C interface, then I would propose that that functionality
should be in a separate python layer (above the binding) with its own
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>

bug in emacs-ui ?

[Carl Worth]

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', 'point-invisible-p' nor 
> 'forward-char' in there:
> http://patch-tracker.debian.org/package/emacs23/23.3+1-1

Perhaps I was confused. I thought 23.3.1 was a distinct upstream release

hiding xapian symbols

[David Bremner]

On Tue, 21 Jun 2011 22:05:15 -0400, Daniel Kahn Gillmor  wrote:
> However, i'm concerned that the act of hiding these symbols will make it
> so that any program that tries to link both libnotmuch and libxapian
> will be unable to use these symbols.
> 
> This makes me think that a program that links against libnotmuch and
> libxapian, but actually tries to *use* libxapian's exception handling
> may have a problem.
> 

This seems to work, when compiled "g++ foo.c -lnotmuch -lxapian"

I get 

,
| Error opening database at /nonexistant/.notmuch: No such file or directory
| caught Cannot create directory `/nonexistant'
`

don't run it as root ;)

#include 
#include 
#include 
main (int argc, char **argv){

notmuch_database_t *notmuch
  = notmuch_database_open ("/nonexistant",
 NOTMUCH_DATABASE_MODE_READ_ONLY);

  try{
(void)new Xapian::WritableDatabase ("/nonexistant",
Xapian::DB_CREATE_OR_OPEN);
  } catch (const Xapian::Error ) {
printf("caught %s\n",error.get_msg().c_str());
  }
}

[PATCH] tests: add a test for symbol hiding side effects

[david]

From: David Bremner brem...@debian.org

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 +
 4 files changed, 40 insertions(+), 1 deletions(-)
 create mode 100755 test/symbol-hiding
 create mode 100644 test/symbol-test.cc

diff --git a/test/basic b/test/basic
index 808c968..d6e8c10 100755
--- a/test/basic
+++ b/test/basic
@@ -56,7 +56,7 @@ tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
 available=$(ls -1 ../ | \
 sed -r -e 
/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d \
   -e 
/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d \
-  -e 
/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d \
+  -e 
/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d
 \
   -e /^(test.expected-output|.*~)/d \
   -e /^(gnupg-secret-key.asc)/d \
   -e /^(gnupg-secret-key.NOTE)/d \
diff --git a/test/notmuch-test b/test/notmuch-test
index 83f284d..fe85c6a 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -40,6 +40,7 @@ TESTS=
   emacs-large-search-buffer
   maildir-sync
   crypto
+  symbol-hiding
 
 TESTS=${NOTMUCH_TESTS:=$TESTS}
 
diff --git a/test/symbol-hiding b/test/symbol-hiding
new file mode 100755
index 000..1c1f34e
--- /dev/null
+++ b/test/symbol-hiding
@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2011 David Bremner
+#
+
+test_description='exception symbol test
+
+This test tests whether hiding Xapian::Error symbols in libnotmuch
+also hides them for other users of libxapian. This is motivated by
+the discussion in http://gcc.gnu.org/wiki/Visibility'
+
+. ./test-lib.sh
+
+output=Error opening database at /nonexistant/.notmuch: No such file or 
directory
+caught No chert database found at path \`/nonexistant'
+
+g++ -o symbol-test ../symbol-test.cc -L../lib -lnotmuch -lxapian
+test_expect_success $message ./symbol-test
+test_done
+
+
diff --git a/test/symbol-test.cc b/test/symbol-test.cc
new file mode 100644
index 000..f077845
--- /dev/null
+++ b/test/symbol-test.cc
@@ -0,0 +1,17 @@
+#include stdio.h
+#include xapian.h
+#include notmuch.h
+main (int argc, char **argv){
+
+notmuch_database_t *notmuch
+  = notmuch_database_open (/nonexistant,
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+
+  try{
+(void)new Xapian::WritableDatabase (/nonexistant,
+   Xapian::DB_OPEN);
+  } catch (const Xapian::Error error) {
+printf(caught %s\n,error.get_msg().c_str());
+  }
+  return 0;
+}
-- 
1.7.5.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug in emacs-ui ?

[Carl Worth]

On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet seb.bi...@gmail.com wrote:
 On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth cwo...@cworth.org 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', 'point-invisible-p' nor 
 'forward-char' in there:
 http://patch-tracker.debian.org/package/emacs23/23.3+1-1

Perhaps I was confused. I thought 23.3.1 was a distinct upstream release
From 23.3, but maybe not, (emacs version numbers use 1-based indexing
perhaps?).

 anyways... for the moment I'll just live with it...

Sorry about that.

 except if somebody has some insights on how to catch the 'End of
 buffer' error and add some more protective programming around the
 'scroll-up' function ?

My emacs lisp skills are primarily restricted to actual
experimentation. So if I can replicate the bug, I might be able to find
a fix. I'm not very good at doing theoretical fixes with emacs lisp
code.

-Carl


pgpFoPwpDytML.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Python updates

[Carl Worth]

On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth sebast...@sspaeth.de 
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 good point.

But the same confusion can happen to someone using notmuch tag and
then switching to using notmuch_message_add_tag at the C library
interface.

That's what I meant when I said that if there's an inconsistency here,
then we should fix it at the C library interface, and not just in a
language-specific wrapper.

 See above, people don't consider using the libnotmuch API, they tag a
 message via python and it behaves differently than tag a message via
 notmuch binary
 So we'll have some level of inconsistency in any case. :)

Let's figure out one right answer for the library interface, (regardless
of language) and implement that.

 Would you be happy to have maildir syncing disabled by default and users
 can enable it via a parameter?

I'd be happy to hear a proposal to add a parameter to the library
interface for maildir syncing, (and I wouldn't even be opposed to having
it enabled by default).

The only thing I care about strongly here is that we have a single
library interface. I don't want one interface in C, a different
interface in python, (and different interfaces in go, ruby, etc.).

Sometimes a language will provide some convenient builtin handling for
something that's awkward at the notmuch C interface, (such as a native
interface for iterators). And I definitely don't mind a language binding
using something like that as opposed to manually binding every
iteration-supporting function that we have in the notmuch library.

But I don't want to see semantic changes to the interface that don't
have anything to do with the language itself.

 I do see why you want to achieve consistency with the API.

Thanks.

 On the other hand are the python API somewhat more highlevel than the
 low-level API calls, and we provide a few convenience functions that
 are not available in the API at all.

That's not the stance I'd like to see.

If you want convenience in the python interface that doesn't exist in
the C interface, then let's start by fixing the C interface.

If there's convenience you want in the python interface that shouldn't
exist in the C interface, then I would propose that that functionality
should be in a separate python layer (above the binding) with its own
name.

What do you think?

-Carl

-- 
carl.d.wo...@intel.com


pgpwEMfEAIRQE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v6 00/17] Fix 'notmuch new' atomicity issues

[Austin Clements]

Ping.

On Sat, Jun 11, 2011 at 4:04 PM, Austin Clements amdra...@mit.edu 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 Monday while stuck on a plane,
 but an opportunity presented itself when I needed something better to
 do than fix the sink.  As a result, if you can look over this before
 Monday, I can use that time to address any further comments.)

 The beginning of the sequence---test: Fix message when skipping
 test_expect_equal* tests through new: Defer updating directory
 mtimes until the end.---has not changed besides than the minor things
 you pointed out earlier.  Here's a quick summary of the differences in
 the rest of the sequence:

 lib: Add notmuch_database_{begin,end}_atomic.
  Rebased but otherwise identical.

 lib: Add support for nested atomic sections.
  New.

 lib: Indicate if there are more filenames after removal.
  Rebased but otherwise identical.

 lib: Remove message document directly after removing the last file
 name.
  New.  Supersedes the patches that rewrote
  notmuch_database_remove_message and made sync delete messages.

 lib: Add an API to find a message by filename.
  Culled from lib: Add API's to find by filename and ... in the old
  series.  What I kept is identical.

 lib: Wrap notmuch_database_add_message in an atomic section.
  New.

 new: Cleanup. Put removed/renamed message count in add_files_state_t.
 new: Cleanup. De-duplicate file name removal code.
  Both new, but closely related to previous remove_filename patch.

 new: Synchronize maildir flags eagerly.
  New, but very closely related to previous patch of the same name.
  This patch is simpler now because of the previous two cleanups.

 new: Wrap adding and removing messages in atomic sections.
  Rebased and added an atomic section around removal.

 lib: Improve notmuch_database_{add,remove}_message documentation.
  New.

 Ultimately, I still think the existing removal API is weird because it
 forces you to do things like lookup a message by file name just in
 case you need that message object after removal tells you that it
 didn't actually remove the message.  But I don't know what to do about
 it that isn't equally weird.

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: Show all multipart/alternative parts by default.

[Jameson Graef Rollins]

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, no content will be displayed.

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.

Since we want to move forward with the next release, we're going to
set this variable true by default, to make sure that no content is
unretrievably hidden from the user.  Once we come up with a better
solution for easy display of hidden parts we can set this back to a
default value of 'nil'.
---
 emacs/notmuch-show.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0d9b52a..af1d44b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -96,7 +96,7 @@ same as that of the previous message.
 notmuch-wash-excerpt-citations))
 
 ;; Mostly useful for debugging.
-(defcustom notmuch-show-all-multipart/alternative-parts nil
+(defcustom notmuch-show-all-multipart/alternative-parts t
   Should all parts of multipart/alternative parts be shown?
   :group 'notmuch
   :type 'boolean)
-- 
1.7.5.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: When will we have our next release?

[Carl Worth]

On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins 
jroll...@finestructure.net 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
 completely handle this together, and I'm sure we can get others to
 help.

Excellent!

 But the mechanics of the actual release are not the problem.  The
 problem is the current one-person bottleneck for all patches:

This is a problem if master isn't moving, I agree. And that has been a
problem in the past.

More recently, master has been moving just fine, and I have proven to
get too caught up in oh, just a few more bug fixes to merge... to just
sit down and make a release. So that's what I want to fix now.

To that end, I've just nominated David Bremner as our release
manager. He's already been pushing packages of recent notmuch master to
Debian experimental, so he's effectively already in the role of choosing
particular code states that the masses can easily get their hands on.

I've asked him to just take over the release process from here and I've
pretty much left all decisions in his hands. He'll probably make a
separate branch for the release at some point, (in the primary
repository). I'll let him talk more about plans if he needs to.

 This is *not* meant to be an indictment of you at all.  I know it's
 incredibly hard to keep up with the incoming patch flow.  It takes a lot
 of time and work to review every patch.  I also really like your
 reviews.  They are incredibly thorough and insightful, and I always
 learn from them.

Thanks. That's very kind of you to say so.

 I would really like to continue to get your review of patches.  I think
 they're just too valuable.  So it would be really nice if one of the
 solutions was a way to just grease the bottleneck, so to speak.  For
 instance, if you could commit to reviewing just 1 patch series a week we
 would be way ahead of where we have been.

I can't really promise anything other than doing the best I can to stay
on top of things. Lately, I am at least using notmuch itself more
effectively to manage outstanding patches and this is helping I thinl.

 Another thing that would help would be to delegate responsibility of
 certain components to others, as you have with the python binding to
 spaetz.  For instance, we have at least a couple of elisp experts
 hanging around.  Maybe you could cede handling of all emacs patches to
 someone like jkr or dme, and to felipe for vim, etc. (if they're willing
 to take on those rolls).  That would help reduce your burden a bit.

Yes! For people that are already effectively maintaining isolated
portions of the code, I'm more than happy to delegate full editorial
control over those pieces, (and allow direct pushes, etc.). This has
actually already been happening with python and vim pieces. And I plan
to add some new mutt code soon with its own maintainer.

And the delegation of release management that I'm announcing here will
help too.

 We could also formalize some sort of tiered review system.  amdragon has
 been doing a really good job of frequently providing good review of
 patches on list.  I think that any proposed patch that gets a thumbs up
 From someone like amdragon should immediately be elevated in your queue,
 or just applied out-right.  If the review of others explicitly helped
 get patches merged faster, I'm quite sure it would encourage more folks
 to submit their reviews as well.

I would love to have more review from anyone. I don't think there's any
need to formalize anything.

Much of it can be as simple as watching things you've seen me do and
then doing them yourself. For example, there are a lot of recent patches
that I merged only after I wrote a test case for the bug fix. It's quite
a bottleneck for me to write new tests like that. If other people could
review patches and ask for test cases, or write test cases themselves,
then that would definitely relieve a burden on my part.

Similarly, I think the most regular coders on the project have come to
understand what I expect from commit messages. So that's something else
that's pretty easy for anyone to review.

So, yes, please help in the review process, everybody! I don't think I
have any particularly exclusive talent with regard to judging code to be
clean and in good taste. I definitely appreciate the good sense of taste
that many on this list are demonstrating regularly.

 Notmuch is an incredible project, with an absolutely incredible
 development community.  It's an absolute joy to work on.

I absolutely agree. I haven't taken the opportunity often enough to say
thank you to everyone who has contributed!

So, thanks!

It's such a wonderful thing to me to see so many good people working
hard and having fun to collectively make such a fun tool![*]

 If we can just grease the wheels a little bit to get 

Notmuch 0.6: Let's do it.

[David Bremner]

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 branch now from the main notmuch repo. 

2) Add id:1308791652-17372-2-git-send-email-jroll...@finestructure.net
   or equivalent 

3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
   and July 1.

4) Release July 1.

The next release will approximately August 1, with a feature freeze
around July 23.  Normally this might be a lousy time for a release, but
some of us will be hacking in Banja Luka the week before.

David

[1] In the traditional manner, Jamie has done most of the work, and I am
swooping in at the last minute to steal credit ;).

[2] If you have to ask who decides what is _important_, you haven't
understood the release tyrant concept completely.





pgpGbyF8CmNNP.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Show all multipart/alternative parts by default.

[David Bremner]

On Wed, 22 Jun 2011 18:14:12 -0700, Jameson Graef Rollins 
jroll...@finestructure.net 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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch