[notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread micah anderson
On Wed, 03 Feb 2010 18:37:57 -0500, Jameson Rollins  wrote:
> On Thu, 4 Feb 2010 09:41:41 +1300, martin f krafft  
> wrote:
> > also sprach David Bremner  [2010.02.04.0924 +1300]:
> > > > PS: speaking of prefixes, how about remving the subject prefix of
> > > > this list in general? ;)
> > > 
> > > I used to agree, but in notmuch, I actually find it convenient to have
> > > threads marked by mailing list. Perhaps this will change if/when my
> > > email setup or the notmuch emacs ui get better...
> > 
> > sed -e 's,^Subject:,& [notmuch],'
> 
> I think I might agree with Martin.  The subject prefix doesn't really
> seem necessary with notmuch, considering that for the following two
> searches:
> 
> notmuch search to:notmuch at notmuchmail.org
> notmuch search subject:[notmuch]

That is because xapian doesn't doesn't ount [] as words so doesn't index
them[0].

micah


0. according to kanru on IRC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/2b6f4796/attachment.pgp>


[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread Servilio Afre Puentes
On 3 February 2010 15:18, martin f krafft  wrote:
> also sprach Marten Veldthuis  [2010.02.04.0353 
> +1300]:
>> > Like this? http://notmuchmail.org/recentchanges/
>>
>> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki
>
> To my knowledge, neither of these two give you diffs. This is what
> a post-receive hook offers.

In the second link, the links with the text "commitdiff" provide it,
and you have the Atom and RSS feeds at the bottom.

Servilio


[notmuch] Git feature branch

2010-02-03 Thread Jameson Rollins
On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth  wrote:
> I want to maintain a branch myself, (where I'm the only person pushing
> to the branch). [This is different than what I've done with the cairo
> repository where we have all core maintainer's pushing to a central
> repository. I'm intentionally trying something new here.]

Just my 2 cents here, but I fully support the idea of perusing a fully
distributed development model.  I have been using it on other projects I
work on and it works great.

> Obviously, that branch that I maintain is currently called "master", but
> I wouldn't mind (and might actually prefer) to have it be called
> "~cworth" or so. Though we have the problem that we need "master" to
> point to *something*.

There's really no need to do that.  For others developers, they would
just add your repo as a "remote", which would presumably be named
something like "cworth".  Then in the developers repo your master branch
would be named "cworth/master".

With a crew of developers, A, B, C, etc., each one would add the others
as remotes, and their branches would be visible under their remotes, ie:

C at host:~$ git branch -a
master
foo
bar
remotes/A/master
remotes/A/foo
remotes/B/master
remotes/B/foo
...

> Beyond that, I'm quite happy to have any number of branches similarly
> maintained by any other individuals. I want to get things setup so that
> those will be hosted and listed alongside my branch on
> notmuchmail.org. And I'll be happy to accept pull requests from
> people. I expect to find people naturally gravitating to "ownership" or
> particular portions of the code, where I will gain a lot of trust for
> particular maintainers over the code they own.

I think this is the right idea.

I think the problem we've been having recently is that we have bit of a
patch backlog due to circumstances of Carl's travel.  This is an issue
because the project is new and people are eager to see their
contributions in place.  I'm sure Carl will get to them as fast as he
can.  Once the project becomes more mature and other developers are
vetting patches, then their branches can take over as "master" in the
absence of an outdated canonical master.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/2f37c13f/attachment.pgp>


[notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread David Bremner
On Wed, 03 Feb 2010 18:37:57 -0500, Jameson Rollins  wrote:
> 
> I think I might agree with Martin.  The subject prefix doesn't really
> seem necessary with notmuch, considering that for the following two
> searches:
> 
> notmuch search to:notmuch at notmuchmail.org
> notmuch search subject:[notmuch]

Not to belabour the point, but I am talking about scanning my inbox
visually in emacs.

d


[notmuch] Git feature branch

2010-02-03 Thread Carl Worth
On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft  
wrote:
> I discussed this with Carl at LCA a bit and ideally we should come
> up with a way to relieve Carl of the bottleneck burden (obviously
> without stealing away his dictator hat ;)

Sounds great! Let's keep working together and find ways to help our
community work together. And I really appreciate all the help!

> I think it would make sense to move the mainline to git.debian.org
> for now, or another place where everyone can easily get an account.
> As alternatives I propose repo.or.cz. I'd prefer to stay away from
> commercial services like Github.

I'm glad to help make things work on notmuchmail.org directly. I don't
have a problem giving out shell access to people who want to help set
things up the way we want. (And prototyping things elsewhere is fine
too.)

> Once we're there, how about copying the branch structure from
> Git development[0]:
> 
>   maint/? the stable release
>   master/   ? the stablising head
>   next/ ? testing branch
>   pu/   ? patch integration branch (proposed updates)

I'm not a fan of this scheme, (or maybe I've just never quite understood
it).

When I first encountered this scheme, (when first using git), it was
never clear to me what branch I should actually run or test as a
user. Nor was it obvious which branches would be regularly rebased or
not---nor which branches had features being discussed on the mailing
list.

Here are some of my thoughts:

Instead of "maint" I'd much rather just have branches that are named
directly after the stable releases being maintained. We've done this
with the cairo repository with branch names like "1.2", "1.4", "1.6",
etc. That way it's very clear what the branch represents and it's
possible to have multiple concurrent "live" maintenance branches. But of
course, until we actually have releases, this doesn't really matter. :-)

I want to maintain a branch myself, (where I'm the only person pushing
to the branch). [This is different than what I've done with the cairo
repository where we have all core maintainer's pushing to a central
repository. I'm intentionally trying something new here.]

Obviously, that branch that I maintain is currently called "master", but
I wouldn't mind (and might actually prefer) to have it be called
"~cworth" or so. Though we have the problem that we need "master" to
point to *something*.

Beyond that, I'm quite happy to have any number of branches similarly
maintained by any other individuals. I want to get things setup so that
those will be hosted and listed alongside my branch on
notmuchmail.org. And I'll be happy to accept pull requests from
people. I expect to find people naturally gravitating to "ownership" or
particular portions of the code, where I will gain a lot of trust for
particular maintainers over the code they own.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list

I definitely like the patches on the list. I find that with notmuch, I
can maintain a queue of outstanding patches very effectively, (meaning,
that the queue is usable and doesn't forget even if I do get very far
behind like I am currently).

> master or pu (or even maint/next), as appropriate? Use the Debian
> bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> manager on notmuchmail.org? Use patchwork [1]?

I'm personally not interested in any system that requires me to push any
additional buttons outside of notmuch and git itself. I am interested in
tools that can generate reports and help provide visibility into
things. So patchwork fixed to automatically notice when patches are
merged would be interesting. Also interesting would be support for
publishing my notmuch-based queue of patches to a web page.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/75d8d745/attachment.pgp>


[notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread Jameson Rollins
On Thu, 4 Feb 2010 09:41:41 +1300, martin f krafft  
wrote:
> also sprach David Bremner  [2010.02.04.0924 +1300]:
> > > PS: speaking of prefixes, how about remving the subject prefix of
> > > this list in general? ;)
> > 
> > I used to agree, but in notmuch, I actually find it convenient to have
> > threads marked by mailing list. Perhaps this will change if/when my
> > email setup or the notmuch emacs ui get better...
> 
> sed -e 's,^Subject:,& [notmuch],'

I think I might agree with Martin.  The subject prefix doesn't really
seem necessary with notmuch, considering that for the following two
searches:

notmuch search to:notmuch at notmuchmail.org
notmuch search subject:[notmuch]

the first is actually more reliable for finding list messages.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/971e6031/attachment.pgp>


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
On Wed, 03 Feb 2010 08:47:41 -0800, Carl Worth  wrote:
> See this page for details (particularly the "security" and
> "infelicities" sections):
> 
>   http://ikiwiki.info/tips/untrusted_git_push/

Ah. Probably this section:

  So, unless you have the attachment plugin turned on, non-page files
  cannot be added. And if it's turned on, whatever allowed_attachments
  checks you have configured will also check files pushed into git.

since I was trying to add some screenshots of the Emacs interface. It
makes perfect sense not to enable this plugin though, given the security
implications (people could potentially upload mp3's as png's etc).

Let me know if I should send you the commit off-list or if you don't
mind enabling the attachment plugin for eg common image filetypes.

-- 
- Marten


[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread David Bremner
On Thu, 4 Feb 2010 09:18:29 +1300, martin f krafft  
wrote:

> PS: speaking of prefixes, how about remving the subject prefix of
> this list in general? ;)

I used to agree, but in notmuch, I actually find it convenient to have
threads marked by mailing list. Perhaps this will change if/when my
email setup or the notmuch emacs ui get better...

d


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
On Wed, 03 Feb 2010 09:36:52 -0500, Matthew Gregg  wrote:
> Like this? http://notmuchmail.org/recentchanges/

No, more like this: http://git.notmuchmail.org/git/notmuch-wiki

-- 
- Marten


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:
> The benefit is that there's now a git repository for the website, (with
> source in markdown format), and more importantly, the git repository
> will accept a "git push" without any authentication necessary.

Carl, I'm getting 

  To git://notmuchmail.org/git/notmuch-wiki
   ! [remote rejected] master -> master (pre-receive hook declined)

upon pushing. Some part of the "without any authentication" is not
working, I suspect. :)

-- 
- Marten


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
On Wed, 03 Feb 2010 08:23:18 -0500, micah anderson  wrote:
> I don't know ikiwiki that well, but I imagine there is a way (probably
> via a git post-commit hook) to email changes that have been pushed. This
> might be a good way to keep up with what people are changing on the
> site, although sending it to this list might be too much, perhaps
> another mailing list for those gluttons who would like to see this?

Wouldn't RSS from gitweb be sufficient? There's already RSS for
notmuch.git, I expect it'd be trivial to publish the same for
notmuch-wiki.git.

-- 
- Marten


[notmuch] [PATCH 4/4] Content of the test script updated to the new framework

2010-02-03 Thread Michal Sojka
The changes are:
- Removed helper functions which were moved to test-lib.sh
- Replaced every echo with test_expect_success.
- Replaced $NOTMUCH with notmuch (test-lib.sh sets $PATH appropriately)
- Test commands chained with && (test-lib.sh doesn't use "set -e" in
  order to complete the test suite even if something fails)
- Quoted ${MAIL_DIR} and other variables as they contains spaces
- ${TEST_DIR} replaced by ./

To run the whole test suite run
make

To run only the converted test
   ./t0001-notmuch-new.sh

To stop on the first error
   ./t0001-notmuch-new.sh -i
then mail store and database can be inspected in
"trash directory.t0001-notmuch-new"

To see the output of tests
   ./t0001-notmuch-new.sh -v

To not remove trash directory at the end:
   ./t0001-notmuch-new.sh -d

Signed-off-by: Michal Sojka 
---
 test/t0001-notmuch-new.sh |  310 -
 1 files changed, 108 insertions(+), 202 deletions(-)

diff --git a/test/t0001-notmuch-new.sh b/test/t0001-notmuch-new.sh
index d7b85c0..52c64e9 100755
--- a/test/t0001-notmuch-new.sh
+++ b/test/t0001-notmuch-new.sh
@@ -1,220 +1,126 @@
 #!/bin/sh
-set -e

-find_notmuch_binary ()
-{
-dir=$1
+test_description='Description of this test...
+This test checks if command xyzzy does the right thing...
+'
+. ./test-lib.sh

-while [ -n "$dir" ]; do
-   bin=$dir/notmuch
-   if [ -x $bin ]; then
-   echo $bin
-   return
-   fi
-   dir=$(dirname $dir)
-   if [ "$dir" = "/" ]; then
-   break
-   fi
-done
-
-echo notmuch
-}
-
-# Generate a new message in the mail directory, with
-# a unique message ID and subject.
-#
-# The filename of the message generated is available as
-# $gen_msg_filename
-gen_msg_cnt=0
-gen_msg_filename=""
-generate_message ()
-{
-gen_msg_cnt=$((gen_msg_cnt + 1))
-gen_msg_name=msg-$(printf "%03d" $gen_msg_cnt)
-
-if [ "$#" = "0" ]; then
-   gen_msg_filename="${MAIL_DIR}/$gen_msg_name"
-else
-   gen_msg_filename="${MAIL_DIR}/$1/$gen_msg_name"
-   mkdir -p $(dirname $gen_msg_filename)
-fi
-
-cat <$gen_msg_filename
-From: Notmuch Test Suite 
-To: Notmuch Test Suite 
-Message-Id: 
-Subject: Test message ${gen_msg_filename}
-Date: Tue, 05 Jan 2010 15:43:57 -0800
-
-This is just a test message at ${gen_msg_filename}
-EOF
-}
-
-do_sleep ()
-{
-sleep 1
-}
-
-TEST_DIR=$(pwd)/test.$$
-MAIL_DIR=${TEST_DIR}/mail
-export NOTMUCH_CONFIG=${TEST_DIR}/notmuch-config
-NOTMUCH=$(find_notmuch_binary $(pwd))
-
-rm -rf ${TEST_DIR}
-mkdir ${TEST_DIR}
-cd ${TEST_DIR}
-
-mkdir ${MAIL_DIR}
-
-cat < ${NOTMUCH_CONFIG}
-[database]
-path=${MAIL_DIR}
-
-[user]
-name=Notmuch Test Suite
-primary_email=test_suite at notmuchmail.org
-EOF
-
-echo "### Testing \"notmuch new\" with no messages"
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 new message"
+test_expect_success "Testing \"notmuch new\" with no messages" '
+notmuch new
+'
 do_sleep
-generate_message
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 2 new messages"
+test_expect_success "Testing \"notmuch new\" with 1 new message" '
+generate_message &&
+notmuch new
+'
 do_sleep
-generate_message
-generate_message
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with no new messages (and a non-empty 
database)"
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with two new directories (one mail)"
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-mkdir ${MAIL_DIR}/def
-mkdir ${MAIL_DIR}/ghi
-generate_message def
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with two new directories (one 
mail)---opposite inode order"
-
-rm -rf ${MAIL_DIR}/.notmuch
-mv ${MAIL_DIR}/ghi ${MAIL_DIR}/abc
-rm ${MAIL_DIR}/def/*
-generate_message abc
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 old message moved into the mail store"
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-generate_message
-tmp_msg_filename=tmp/$gen_msg_filename
-mkdir -p $(dirname $tmp_msg_filename)
-mv $gen_msg_filename $tmp_msg_filename
+test_expect_success "Testing \"notmuch new\" with 2 new messages" '
+generate_message &&
+generate_message &&
+notmuch new
+'
+test_expect_success "Testing \"notmuch new\" with no new messages (and a 
non-empty database)" '
+notmuch new
+'
+test_expect_success "Testing \"notmuch new\" with two new directories (one 
mail)" '
+rm -rf "${MAIL_DIR}"/* "${MAIL_DIR}"/.notmuch &&
+mkdir "${MAIL_DIR}/def" &&
+mkdir "${MAIL_DIR}/ghi" &&
+generate_message def &&
+notmuch new
+'
+test_expect_success "Testing \"notmuch new\" with two new directories (one 
mail)---opposite inode order" '
+rm -rf "${MAIL_DIR}/.notmuch" &&
+mv "${MAIL_DIR}/ghi" "${MAIL_DIR}/abc" &&
+rm "${MAIL_DIR}/def/"* &&
+generate_message abc &&
+notmuch new
+'
+test_expect_success "Testing \"notmuch new\" with 1 old message moved into the 
mail store" '
+rm -rf "${MAIL_DIR}/"* "${MAIL_DIR}/.notmuch" &&
+generate_message &&
+tmp_msg_filename="tmp/notmuch-${this_test}/$(basename 

[notmuch] [PATCH 3/4] Rename notmuch-test according to the new naming scheme

2010-02-03 Thread Michal Sojka
Signed-off-by: Michal Sojka 
---
 test/notmuch-test |  220 -
 test/t0001-notmuch-new.sh |  220 +
 2 files changed, 220 insertions(+), 220 deletions(-)
 delete mode 100755 test/notmuch-test
 create mode 100755 test/t0001-notmuch-new.sh

diff --git a/test/notmuch-test b/test/notmuch-test
deleted file mode 100755
index d7b85c0..000
--- a/test/notmuch-test
+++ /dev/null
@@ -1,220 +0,0 @@
-#!/bin/sh
-set -e
-
-find_notmuch_binary ()
-{
-dir=$1
-
-while [ -n "$dir" ]; do
-   bin=$dir/notmuch
-   if [ -x $bin ]; then
-   echo $bin
-   return
-   fi
-   dir=$(dirname $dir)
-   if [ "$dir" = "/" ]; then
-   break
-   fi
-done
-
-echo notmuch
-}
-
-# Generate a new message in the mail directory, with
-# a unique message ID and subject.
-#
-# The filename of the message generated is available as
-# $gen_msg_filename
-gen_msg_cnt=0
-gen_msg_filename=""
-generate_message ()
-{
-gen_msg_cnt=$((gen_msg_cnt + 1))
-gen_msg_name=msg-$(printf "%03d" $gen_msg_cnt)
-
-if [ "$#" = "0" ]; then
-   gen_msg_filename="${MAIL_DIR}/$gen_msg_name"
-else
-   gen_msg_filename="${MAIL_DIR}/$1/$gen_msg_name"
-   mkdir -p $(dirname $gen_msg_filename)
-fi
-
-cat <$gen_msg_filename
-From: Notmuch Test Suite 
-To: Notmuch Test Suite 
-Message-Id: 
-Subject: Test message ${gen_msg_filename}
-Date: Tue, 05 Jan 2010 15:43:57 -0800
-
-This is just a test message at ${gen_msg_filename}
-EOF
-}
-
-do_sleep ()
-{
-sleep 1
-}
-
-TEST_DIR=$(pwd)/test.$$
-MAIL_DIR=${TEST_DIR}/mail
-export NOTMUCH_CONFIG=${TEST_DIR}/notmuch-config
-NOTMUCH=$(find_notmuch_binary $(pwd))
-
-rm -rf ${TEST_DIR}
-mkdir ${TEST_DIR}
-cd ${TEST_DIR}
-
-mkdir ${MAIL_DIR}
-
-cat < ${NOTMUCH_CONFIG}
-[database]
-path=${MAIL_DIR}
-
-[user]
-name=Notmuch Test Suite
-primary_email=test_suite at notmuchmail.org
-EOF
-
-echo "### Testing \"notmuch new\" with no messages"
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 new message"
-do_sleep
-generate_message
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 2 new messages"
-do_sleep
-generate_message
-generate_message
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with no new messages (and a non-empty 
database)"
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with two new directories (one mail)"
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-mkdir ${MAIL_DIR}/def
-mkdir ${MAIL_DIR}/ghi
-generate_message def
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with two new directories (one 
mail)---opposite inode order"
-
-rm -rf ${MAIL_DIR}/.notmuch
-mv ${MAIL_DIR}/ghi ${MAIL_DIR}/abc
-rm ${MAIL_DIR}/def/*
-generate_message abc
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 old message moved into the mail store"
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-generate_message
-tmp_msg_filename=tmp/$gen_msg_filename
-mkdir -p $(dirname $tmp_msg_filename)
-mv $gen_msg_filename $tmp_msg_filename
-do_sleep
-$NOTMUCH new > /dev/null
-do_sleep
-mv $tmp_msg_filename $gen_msg_filename
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 renamed message"
-
-do_sleep
-generate_message
-$NOTMUCH new > /dev/null
-do_sleep
-mv $gen_msg_filename ${gen_msg_filename}-renamed
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with 1 deleted message"
-
-do_sleep
-rm ${gen_msg_filename}-renamed
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a new directory with 3 messages"
-
-do_sleep
-generate_message dir
-generate_message dir
-generate_message dir
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a renamed directory of 3 messages"
-
-do_sleep
-mv ${MAIL_DIR}/dir ${MAIL_DIR}/dir-renamed
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a deleted directory of 3 messages"
-
-do_sleep
-rm -rf ${MAIL_DIR}/dir-renamed
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a new directory with 3 messages (tail 
of list)"
-
-do_sleep
-generate_message zzz
-generate_message zzz
-generate_message zzz
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a deleted directory of 3 messages (tail 
of list)"
-
-do_sleep
-rm -rf ${MAIL_DIR}/zzz
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a symlink to an external directory of 1 
message"
-
-rm -rf ${MAIL_DIR}/.notmuch
-mv ${MAIL_DIR} ${TEST_DIR}/actual_maildir
-
-mkdir ${MAIL_DIR}
-ln -s ${TEST_DIR}/actual_maildir ${MAIL_DIR}/symlink
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a symlink to an external file"
-do_sleep
-generate_message
-external_msg_filename=${TEST_DIR}/external/$(basename $gen_msg_filename)
-mkdir -p $(dirname $external_msg_filename)
-mv $gen_msg_filename $external_msg_filename
-ln -s $external_msg_filename $gen_msg_filename
-
-$NOTMUCH new
-
-echo "### Testing \"notmuch new\" with a two-level directory with 3 files"
-
-do_sleep
-generate_message two/levels

[notmuch] [PATCH 2/4] Update test framework for use with notmuch

2010-02-03 Thread Michal Sojka
This removes Git specific things from the test-lib.sh and adds helper
functions for notmuch taken from Carl's test script.

Signed-off-by: Michal Sojka 
---
 test/t-basic.sh |  332 +++
 test/test-lib.sh|  218 +++---
 2 files changed, 88 insertions(+), 462 deletions(-)

diff --git a/test/t-basic.sh b/test/t-basic.sh
index f4ca4fc..cc2ca21 100755
--- a/test/t-basic.sh
+++ b/test/t-basic.sh
@@ -5,46 +5,39 @@

 test_description='Test the very basics part #1.

-The rest of the test suite does not check the basic operation of git
-plumbing commands to work very carefully.  Their job is to concentrate
-on tricky features that caused bugs in the past to detect regression.
-
-This test runs very basic features, like registering things in cache,
-writing tree, etc.
-
-Note that this test *deliberately* hard-codes many expected object
-IDs.  When object ID computation changes, like in the previous case of
-swapping compression and hashing order, the person who is making the
-modification *should* take notice and update the test vectors here.
+Tests the test framework itself.
 '
-
 
 # It appears that people try to run tests without building...

-../git >/dev/null
-if test $? != 1
+if ! test -x ../notmuch
 then
-   echo >&2 'You do not seem to have built git yet.'
+   echo >&2 'You do not seem to have built notmuch yet.'
exit 1
 fi

 . ./test-lib.sh

 
-# git init has been done in an empty repository.
-# make sure it is empty.
+# Test mail store prepared in test-lib.sh
+
+test_expect_success \
+'test that mail store was created' \
+'test -d "${MAIL_DIR}"'
+

-find .git/objects -type f -print >should-be-empty
+find "${MAIL_DIR}" -type f -print >should-be-empty
 test_expect_success \
-'.git/objects should be empty after git init in an empty repo.' \
+'mail store should be empty' \
 'cmp -s /dev/null should-be-empty'

-# also it should have 2 subdirectories; no fan-out anymore, pack, and info.
-# 3 is counting "objects" itself
-find .git/objects -type d -print >full-of-directories
 test_expect_success \
-'.git/objects should have 3 subdirectories.' \
-'test $(wc -l < full-of-directories) = 3'
+'NOTMUCH_CONFIG is set and points to an existing file' \
+'test -f "${NOTMUCH_CONFIG}"'
+
+test_expect_success \
+'PATH is set to this repository' \
+'test "`echo $PATH|cut -f1 -d:`" = "`dirname ${TEST_DIRECTORY}`"'

 
 # Test harness
@@ -73,296 +66,5 @@ then
exit 1
 fi

-
-# Basics of the basics
-
-# updating a new file without --add should fail.
-test_expect_success 'git update-index without --add should fail adding.' '
-test_must_fail git update-index should-be-empty
-'
-
-# and with --add it should succeed, even if it is empty (it used to fail).
-test_expect_success \
-'git update-index with --add should succeed.' \
-'git update-index --add should-be-empty'
-
-test_expect_success \
-'writing tree out with git write-tree' \
-'tree=$(git write-tree)'
-
-# we know the shape and contents of the tree and know the object ID for it.
-test_expect_success \
-'validate object ID of a known tree.' \
-'test "$tree" = 7bb943559a305bdd6bdee2cef6e5df2413c3d30a'
-
-# Removing paths.
-rm -f should-be-empty full-of-directories
-test_expect_success 'git update-index without --remove should fail removing.' '
-test_must_fail git update-index should-be-empty
-'
-
-test_expect_success \
-'git update-index with --remove should be able to remove.' \
-'git update-index --remove should-be-empty'
-
-# Empty tree can be written with recent write-tree.
-test_expect_success \
-'git write-tree should be able to write an empty tree.' \
-'tree=$(git write-tree)'
-
-test_expect_success \
-'validate object ID of a known tree.' \
-'test "$tree" = 4b825dc642cb6eb9a060e54bf8d69288fbee4904'
-
-# Various types of objects
-# Some filesystems do not support symblic links; on such systems
-# some expected values are different
-mkdir path2 path3 path3/subp3
-paths='path0 path2/file2 path3/file3 path3/subp3/file3'
-for p in $paths
-do
-echo "hello $p" >$p
-done
-if test_have_prereq SYMLINKS
-then
-   for p in $paths
-   do
-   ln -s "hello $p" ${p}sym
-   done
-   expectfilter=cat
-   expectedtree=087704a96baf1c2d1c869a8b084481e121c88b5b
-   expectedptree1=21ae8269cacbe57ae09138dcc3a2887f904d02b3
-   expectedptree2=3c5e5399f3a333eddecce7a9b9465b63f65f51e2
-else
-   expectfilter='grep -v sym'
-   expectedtree=8e18edf7d7edcf4371a3ac6ae5f07c2641db7c46
-   expectedptree1=cfb8591b2f65de8b8cc1020cd7d9e67e7793b325
-   

[notmuch] [PATCH 1/4] Copy test framework from Git

2010-02-03 Thread Michal Sojka
Git uses a simple and yet powerfull test framework, written in shell.
The framework is easy to use for both users and developers so I thing
it would help if it is used in notmuch as well.

This is a copy of Git's test framework from commit
b8bba419250711a69e09e7648e5c991f4847a127.

Signed-off-by: Michal Sojka 
---
 test/Makefile |   46 +++
 test/README   |  297 +
 test/aggregate-results.sh |   34 ++
 test/t-basic.sh   |  368 +
 test/test-lib.sh  |  787 +
 5 files changed, 1532 insertions(+), 0 deletions(-)
 create mode 100644 test/Makefile
 create mode 100644 test/README
 create mode 100755 test/aggregate-results.sh
 create mode 100755 test/t-basic.sh
 create mode 100644 test/test-lib.sh

diff --git a/test/Makefile b/test/Makefile
new file mode 100644
index 000..bd09390
--- /dev/null
+++ b/test/Makefile
@@ -0,0 +1,46 @@
+# Run tests
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+-include ../config.mak
+
+#GIT_TEST_OPTS=--verbose --debug
+SHELL_PATH ?= $(SHELL)
+TAR ?= $(TAR)
+RM ?= rm -f
+
+# Shell quote;
+SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
+
+T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
+TSVN = $(wildcard t91[0-9][0-9]-*.sh)
+
+all: pre-clean
+   $(MAKE) aggregate-results-and-cleanup
+
+$(T):
+   @echo "*** $@ ***"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ 
$(GIT_TEST_OPTS)
+
+pre-clean:
+   $(RM) -r test-results
+
+clean:
+   $(RM) -r 'trash directory'.* test-results
+
+aggregate-results-and-cleanup: $(T)
+   $(MAKE) aggregate-results
+   $(MAKE) clean
+
+aggregate-results:
+   '$(SHELL_PATH_SQ)' ./aggregate-results.sh test-results/t*-*
+
+# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
+full-svn-test:
+   $(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
+   $(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=0 LC_ALL=en_US.UTF-8
+
+valgrind:
+   GIT_TEST_OPTS=--valgrind $(MAKE)
+
+.PHONY: pre-clean $(T) aggregate-results clean valgrind
diff --git a/test/README b/test/README
new file mode 100644
index 000..dcd3ebb
--- /dev/null
+++ b/test/README
@@ -0,0 +1,297 @@
+Core GIT Tests
+==
+
+This directory holds many test scripts for core GIT tools.  The
+first part of this short document describes how to run the tests
+and read their output.
+
+When fixing the tools or adding enhancements, you are strongly
+encouraged to add tests in this directory to cover what you are
+trying to fix or enhance.  The later part of this short document
+describes how your test scripts should be organized.
+
+
+Running Tests
+-
+
+The easiest way to run tests is to say "make".  This runs all
+the tests.
+
+*** t-basic.sh ***
+*   ok 1: .git/objects should be empty after git-init in an empty repo.
+*   ok 2: .git/objects should have 256 subdirectories.
+*   ok 3: git-update-index without --add should fail adding.
+...
+*   ok 23: no diff after checkout and git-update-index --refresh.
+* passed all 23 test(s)
+*** t0100-environment-names.sh ***
+*   ok 1: using old names should issue warnings.
+*   ok 2: using old names but having new names should not issue warnings.
+...
+
+Or you can run each test individually from command line, like
+this:
+
+$ sh ./t3001-ls-files-killed.sh
+*   ok 1: git-update-index --add to add various paths.
+*   ok 2: git-ls-files -k to show killed files.
+*   ok 3: validate git-ls-files -k output.
+* passed all 3 test(s)
+
+You can pass --verbose (or -v), --debug (or -d), and --immediate
+(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
+appropriately before running "make".
+
+--verbose::
+   This makes the test more verbose.  Specifically, the
+   command being run and their output if any are also
+   output.
+
+--debug::
+   This may help the person who is developing a new test.
+   It causes the command defined with test_debug to run.
+
+--immediate::
+   This causes the test to immediately exit upon the first
+   failed test.
+
+--long-tests::
+   This causes additional long-running tests to be run (where
+   available), for more exhaustive testing.
+
+--valgrind::
+   Execute all Git binaries with valgrind and exit with status
+   126 on errors (just like regular tests, this will only stop
+   the test script when running under -i).  Valgrind errors
+   go to stderr, so you might want to pass the -v option, too.
+
+   Since it makes no sense to run the tests with --valgrind and
+   not see any output, this option implies --verbose.  For
+   convenience, it also implies --tee.
+
+--tee::
+   In addition to printing the test output to the terminal,
+   write it to files named 't/test-results/$TEST_NAME.out'.
+   As the names depend on the tests' file names, it is safe to
+   run the tests with this option in parallel.
+

[notmuch] Backport of Xapian term update optimisation

2010-02-03 Thread Jameson Rollins
On Thu, 28 Jan 2010 00:06:59 + (UTC), Olly Betts  wrote:
> I've backported the term update optimisation patches
> <http://trac.xapian.org/ticket/250> to Xapian's 1.0 branch, and you can
> find snapshot tarballs including these changes here:
> 
> http://oligarchy.co.uk/xapian/branches/1.0/
> 
> Xapian's testsuite passes (including the additional test coverage which I
> also backported), and I looked over each change carefully, but I would be
> interested to see some real world testing, particularly in the situation
> which these changes are intended to improve (i.e. speed of tagging in
> notmuch).

Hey, Olly.  Thanks so much for backporting this patch and uploading a
patched package to Debian experimental (which is now available):

servo:~ 0$ apt-cache policy libxapian-dev
libxapian-dev:
  Installed: 1.0.17+svn13879-1
  Candidate: 1.0.17+svn13879-1
  Version table:
 *** 1.0.17+svn13879-1 0
  1 http://ftp.us.debian.org experimental/main Packages
100 /var/lib/dpkg/status
 1.0.17-1 0
500 http://debian.lcs.mit.edu testing/main Packages
200 http://ftp.us.debian.org unstable/main Packages
servo:~ 0$ 

I just installed this new version from a Debian experimental repo,
rebuilt notmuch against the new installation, and everything seems to be
working great.  I'll report back any issues to the BTS.  Thanks again.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/72d34a44/attachment.pgp>


[notmuch] Emacs paned UI

2010-02-03 Thread Jameson Rollins
On Mon, 01 Feb 2010 17:05:40 -0800, Tad Fisher  wrote:
> So, I dusted off my Elisp manual and hacked up notmuch.el to support a
> 3-paned UI. This involved the creation of a minor mode (I call it
> notmuch-browse-mode) that manages window state, along with several
> modifications of existing functions to "do the right thing" when we're
> in browse-mode (such as close the "show" window, switch to the "folder"
> window, etc.).

Hey, Tad.  Thanks so much for persuing this!  I was definitely looking
to put something like this together myself, but your elisp foo is a lot
better than mine.  A couple comments:

* I actually would prefer just a two-paned layout, since I don't use
  folders.  Is there a way to configure it to check if there are folders
  defined, and not show the third panel if there isn't?

* I would also like to see the focus remain in the notmuch-search buffer
  all the time, unless I specifically switch to the notmuch-show
  buffer.  I would really like things to behave more like mutt, where
  I'm scrolling through my mail from notmuch-search, but then the
  messages themselves are just being displayed in the lower pane.  Does
  that make sense?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/ac29cdf2/attachment.pgp>


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Jameson Rollins
On Wed, 03 Feb 2010 09:44:46 +0100, "Sebastian Spaeth"  wrote:
> On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:
> 
> > Anyone want to start thinking about a logo design idea... ?
> 
> Although being non-artistic, what about the following design? (Or at
> least along those lines)
> 
> I uploaded it too: http://img194.imageshack.us/img194/2015/notmuchpacman.png

h I like it.

I personally like the super simple aesthetic (even the super simple
original web site).  It matches the notmuch philosophy well.  I think
the pacman logo fits in with that nicely.

The wiki is great, though, since it will allow users to easily
contribute to the documentation.  I've got a bunch of emacs config
tweaks to add.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/65208ae8/attachment.pgp>


[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka  wrote:
> I want it to work the same way as you expected. It seems it would be 
> necessary 
> to modify notmuch_database_remove_message() so that it changes folder term if 
> it detects rename.

On a tangetial issue: It would help if notmuch were able to set an
(optional) flag when detecting a rename. Similar on how it should set
"new" on new messages, a "moved" tag or whatever would make parsing with
3rd party apps much nicer.

E.g. my folder-to-tag syncer could then just look for moved mails and my
MailDirflag-to-notmuchtag syncer could then limit its search also to
"moved" mails, which would be much more efficient.

What do people think?
Basically what I want is:

notmuch.conf:
tag-for-new="inbox unread notspamchecked whatnothere"
tag-for-moved="moved"

Does this make sense?

Sebastian


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Sebastian Spaeth
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:

> Anyone want to start thinking about a logo design idea... ?

Although being non-artistic, what about the following design? (Or at
least along those lines)

I uploaded it too: http://img194.imageshack.us/img194/2015/notmuchpacman.png

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-pacman.png
Type: image/png
Size: 22159 bytes
Desc: logo proposal
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/5ad08ed4/attachment-0001.png>
-- next part --

Sebastian


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Matthew Gregg
Like this? http://notmuchmail.org/recentchanges/

On Wed, 2010-02-03 at 15:19 +0100, Marten Veldthuis wrote:
> On Wed, 03 Feb 2010 08:23:18 -0500, micah anderson  
> wrote:
> > I don't know ikiwiki that well, but I imagine there is a way (probably
> > via a git post-commit hook) to email changes that have been pushed. This
> > might be a good way to keep up with what people are changing on the
> > site, although sending it to this list might be too much, perhaps
> > another mailing list for those gluttons who would like to see this?
> 
> Wouldn't RSS from gitweb be sufficient? There's already RSS for
> notmuch.git, I expect it'd be trivial to publish the same for
> notmuch-wiki.git.
> 


-- 
Matthew Gregg 



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
> /media/mail/mail
> ??? cur
> ?   ??? 1265050537.H891745P1231.samir.ibcsolutions.de:2,S
> ?   ??? 1265050572.H419259P1443.samir.ibcsolutions.de:2,S
> ?   ??? 1265050598.H121639P1634.samir.ibcsolutions.de:2,S
> ?   ??? 1265050617.H309805P1774.samir.ibcsolutions.de:2,S
> ?   ??? 1265050625.H818906P1838.samir.ibcsolutions.de:2,S
> ?   ??? 1265050955.H593083P2020.samir.ibcsolutions.de:2,S

A related question, currently notmuch seems to store the full absolute
path to mails, but I remeber seeing some documentation saying that it's
either absolute or relative to the xapian db dir. Is that correct, or is
it reasonable to assume absolute directories (as e.g. notmuchsync
currently does).

Sebastian


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Carl Worth
On Wed, 03 Feb 2010 09:44:46 +0100, "Sebastian Spaeth"  wrote:
> On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:
> 
> > Anyone want to start thinking about a logo design idea... ?
> 
> Although being non-artistic, what about the following design? (Or at
> least along those lines)
> 
> I uploaded it too: http://img194.imageshack.us/img194/2015/notmuchpacman.png

Cool! Thanks for the contribution.

I like the aesthetic quite a bit, but I'm not sure about the whole
"eating" metaphor. It seems that eating my email is one thing that I
hope notmuch doesn't ever do. ;-)

I don't have enough imagination to come up with a clever visual
representation of "not much" in a logo, but I would love to see
something like that.

-Carl

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


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Carl Worth
On Wed, 03 Feb 2010 15:40:51 +0100, Marten Veldthuis  
wrote:
> Carl, I'm getting 
> 
>   To git://notmuchmail.org/git/notmuch-wiki
>! [remote rejected] master -> master (pre-receive hook declined)

Oh, I'm very glad to hear that! (Though sorry that you are having
difficulties.) I had tried to verify that the pre-receive hook was
active, but I failed.

> upon pushing. Some part of the "without any authentication" is not
> working, I suspect. :)

What's going on is that the pre-receive hook is verifying that any given
push isn't doing anything "bad" according to what's configured in the
wiki. So the fix here is probably just for me to configure the wiki to
tell it that what you're doing isn't actually "bad". Perhaps you're
adding a new page or something, and I haven't configured in that ability
yet?

See this page for details (particularly the "security" and
"infelicities" sections):

http://ikiwiki.info/tips/untrusted_git_push/

The infelicity we have here is that with git-daemon we don't get the actual
error message from the pre-receive hook to tell us what it doesn't
like. Perhaps I should setup a public user that can push via ssh...

In the meantime, if you (or anyone else) can simply email me any commits
that the pre-receive hook doesn't like, then I can figure out how to fix
the ikiwiki configuration to allow them.

Thanks,

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100203/8361390f/attachment-0001.pgp>


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread micah anderson
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:
> So Keith tells me he's entirely unimpressed with my website-design
> skills as evidenced by http://notmuchmail.org .
> 
> In an effort to fix this, I've switched from the single, static HTML
> page that was there previously, to now using ikiwiki to generate a
> remarkably similar-looking, single, static web page.

Your design skills are remarkable at reproducing the same website!

> The benefit is that there's now a git repository for the website, (with
> source in markdown format), and more importantly, the git repository
> will accept a "git push" without any authentication necessary.

This is really cool, thanks for doing this and making it open like this!

I don't know ikiwiki that well, but I imagine there is a way (probably
via a git post-commit hook) to email changes that have been pushed. This
might be a good way to keep up with what people are changing on the
site, although sending it to this list might be too much, perhaps
another mailing list for those gluttons who would like to see this?

micah

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


Re: [notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Sebastian Spaeth
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth cwo...@cworth.org wrote:

 Anyone want to start thinking about a logo design idea... ?

Although being non-artistic, what about the following design? (Or at
least along those lines)

I uploaded it too: http://img194.imageshack.us/img194/2015/notmuchpacman.png

inline: notmuch-pacman.png
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 I want it to work the same way as you expected. It seems it would be 
 necessary 
 to modify notmuch_database_remove_message() so that it changes folder term if 
 it detects rename.

On a tangetial issue: It would help if notmuch were able to set an
(optional) flag when detecting a rename. Similar on how it should set
new on new messages, a moved tag or whatever would make parsing with
3rd party apps much nicer.

E.g. my folder-to-tag syncer could then just look for moved mails and my
MailDirflag-to-notmuchtag syncer could then limit its search also to
moved mails, which would be much more efficient.

What do people think?
Basically what I want is:

notmuch.conf:
tag-for-new=inbox unread notspamchecked whatnothere
tag-for-moved=moved

Does this make sense?

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


Re: [notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread micah anderson
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth cwo...@cworth.org wrote:
 So Keith tells me he's entirely unimpressed with my website-design
 skills as evidenced by http://notmuchmail.org .
 
 In an effort to fix this, I've switched from the single, static HTML
 page that was there previously, to now using ikiwiki to generate a
 remarkably similar-looking, single, static web page.

Your design skills are remarkable at reproducing the same website!

 The benefit is that there's now a git repository for the website, (with
 source in markdown format), and more importantly, the git repository
 will accept a git push without any authentication necessary.

This is really cool, thanks for doing this and making it open like this!

I don't know ikiwiki that well, but I imagine there is a way (probably
via a git post-commit hook) to email changes that have been pushed. This
might be a good way to keep up with what people are changing on the
site, although sending it to this list might be too much, perhaps
another mailing list for those gluttons who would like to see this?

micah



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


[notmuch] [PATCH 3/4] Rename notmuch-test according to the new naming scheme

2010-02-03 Thread Michal Sojka
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
---
 test/notmuch-test |  220 -
 test/t0001-notmuch-new.sh |  220 +
 2 files changed, 220 insertions(+), 220 deletions(-)
 delete mode 100755 test/notmuch-test
 create mode 100755 test/t0001-notmuch-new.sh

diff --git a/test/notmuch-test b/test/notmuch-test
deleted file mode 100755
index d7b85c0..000
--- a/test/notmuch-test
+++ /dev/null
@@ -1,220 +0,0 @@
-#!/bin/sh
-set -e
-
-find_notmuch_binary ()
-{
-dir=$1
-
-while [ -n $dir ]; do
-   bin=$dir/notmuch
-   if [ -x $bin ]; then
-   echo $bin
-   return
-   fi
-   dir=$(dirname $dir)
-   if [ $dir = / ]; then
-   break
-   fi
-done
-
-echo notmuch
-}
-
-# Generate a new message in the mail directory, with
-# a unique message ID and subject.
-#
-# The filename of the message generated is available as
-# $gen_msg_filename
-gen_msg_cnt=0
-gen_msg_filename=
-generate_message ()
-{
-gen_msg_cnt=$((gen_msg_cnt + 1))
-gen_msg_name=msg-$(printf %03d $gen_msg_cnt)
-
-if [ $# = 0 ]; then
-   gen_msg_filename=${MAIL_DIR}/$gen_msg_name
-else
-   gen_msg_filename=${MAIL_DIR}/$1/$gen_msg_name
-   mkdir -p $(dirname $gen_msg_filename)
-fi
-
-cat EOF $gen_msg_filename
-From: Notmuch Test Suite test_su...@notmuchmail.org
-To: Notmuch Test Suite test_su...@notmuchmail.org
-Message-Id: msg-${gen_msg_c...@notmuch-test-suite
-Subject: Test message ${gen_msg_filename}
-Date: Tue, 05 Jan 2010 15:43:57 -0800
-
-This is just a test message at ${gen_msg_filename}
-EOF
-}
-
-do_sleep ()
-{
-sleep 1
-}
-
-TEST_DIR=$(pwd)/test.$$
-MAIL_DIR=${TEST_DIR}/mail
-export NOTMUCH_CONFIG=${TEST_DIR}/notmuch-config
-NOTMUCH=$(find_notmuch_binary $(pwd))
-
-rm -rf ${TEST_DIR}
-mkdir ${TEST_DIR}
-cd ${TEST_DIR}
-
-mkdir ${MAIL_DIR}
-
-cat EOF  ${NOTMUCH_CONFIG}
-[database]
-path=${MAIL_DIR}
-
-[user]
-name=Notmuch Test Suite
-primary_email=test_su...@notmuchmail.org
-EOF
-
-echo ### Testing \notmuch new\ with no messages
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with 1 new message
-do_sleep
-generate_message
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with 2 new messages
-do_sleep
-generate_message
-generate_message
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with no new messages (and a non-empty 
database)
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with two new directories (one mail)
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-mkdir ${MAIL_DIR}/def
-mkdir ${MAIL_DIR}/ghi
-generate_message def
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with two new directories (one 
mail)---opposite inode order
-
-rm -rf ${MAIL_DIR}/.notmuch
-mv ${MAIL_DIR}/ghi ${MAIL_DIR}/abc
-rm ${MAIL_DIR}/def/*
-generate_message abc
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with 1 old message moved into the mail store
-rm -rf ${MAIL_DIR}/* ${MAIL_DIR}/.notmuch
-generate_message
-tmp_msg_filename=tmp/$gen_msg_filename
-mkdir -p $(dirname $tmp_msg_filename)
-mv $gen_msg_filename $tmp_msg_filename
-do_sleep
-$NOTMUCH new  /dev/null
-do_sleep
-mv $tmp_msg_filename $gen_msg_filename
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with 1 renamed message
-
-do_sleep
-generate_message
-$NOTMUCH new  /dev/null
-do_sleep
-mv $gen_msg_filename ${gen_msg_filename}-renamed
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with 1 deleted message
-
-do_sleep
-rm ${gen_msg_filename}-renamed
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a new directory with 3 messages
-
-do_sleep
-generate_message dir
-generate_message dir
-generate_message dir
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a renamed directory of 3 messages
-
-do_sleep
-mv ${MAIL_DIR}/dir ${MAIL_DIR}/dir-renamed
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a deleted directory of 3 messages
-
-do_sleep
-rm -rf ${MAIL_DIR}/dir-renamed
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a new directory with 3 messages (tail 
of list)
-
-do_sleep
-generate_message zzz
-generate_message zzz
-generate_message zzz
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a deleted directory of 3 messages (tail 
of list)
-
-do_sleep
-rm -rf ${MAIL_DIR}/zzz
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a symlink to an external directory of 1 
message
-
-rm -rf ${MAIL_DIR}/.notmuch
-mv ${MAIL_DIR} ${TEST_DIR}/actual_maildir
-
-mkdir ${MAIL_DIR}
-ln -s ${TEST_DIR}/actual_maildir ${MAIL_DIR}/symlink
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a symlink to an external file
-do_sleep
-generate_message
-external_msg_filename=${TEST_DIR}/external/$(basename $gen_msg_filename)
-mkdir -p $(dirname $external_msg_filename)
-mv $gen_msg_filename $external_msg_filename
-ln -s $external_msg_filename $gen_msg_filename
-
-$NOTMUCH new
-
-echo ### Testing \notmuch new\ with a two-level directory with 3 files
-
-do_sleep
-generate_message two/levels
-generate_message two/levels

Re: [notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Jameson Rollins
On Wed, 03 Feb 2010 09:44:46 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth cwo...@cworth.org wrote:
 
  Anyone want to start thinking about a logo design idea... ?
 
 Although being non-artistic, what about the following design? (Or at
 least along those lines)
 
 I uploaded it too: http://img194.imageshack.us/img194/2015/notmuchpacman.png

h I like it.

I personally like the super simple aesthetic (even the super simple
original web site).  It matches the notmuch philosophy well.  I think
the pacman logo fits in with that nicely.

The wiki is great, though, since it will allow users to easily
contribute to the documentation.  I've got a bunch of emacs config
tweaks to add.

jamie.


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


Re: [notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Carl Worth
On Wed, 03 Feb 2010 15:40:51 +0100, Marten Veldthuis mar...@veldthuis.com 
wrote:
 Carl, I'm getting 
 
   To git://notmuchmail.org/git/notmuch-wiki
! [remote rejected] master - master (pre-receive hook declined)

Oh, I'm very glad to hear that! (Though sorry that you are having
difficulties.) I had tried to verify that the pre-receive hook was
active, but I failed.

 upon pushing. Some part of the without any authentication is not
 working, I suspect. :)

What's going on is that the pre-receive hook is verifying that any given
push isn't doing anything bad according to what's configured in the
wiki. So the fix here is probably just for me to configure the wiki to
tell it that what you're doing isn't actually bad. Perhaps you're
adding a new page or something, and I haven't configured in that ability
yet?

See this page for details (particularly the security and
infelicities sections):

http://ikiwiki.info/tips/untrusted_git_push/

The infelicity we have here is that with git-daemon we don't get the actual
error message from the pre-receive hook to tell us what it doesn't
like. Perhaps I should setup a public user that can push via ssh...

In the meantime, if you (or anyone else) can simply email me any commits
that the pre-receive hook doesn't like, then I can figure out how to fix
the ikiwiki configuration to allow them.

Thanks,

-Carl


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


Re: [notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
On Wed, 03 Feb 2010 08:47:41 -0800, Carl Worth cwo...@cworth.org wrote:
 See this page for details (particularly the security and
 infelicities sections):
 
   http://ikiwiki.info/tips/untrusted_git_push/

Ah. Probably this section:

  So, unless you have the attachment plugin turned on, non-page files
  cannot be added. And if it's turned on, whatever allowed_attachments
  checks you have configured will also check files pushed into git.

since I was trying to add some screenshots of the Emacs interface. It
makes perfect sense not to enable this plugin though, given the security
implications (people could potentially upload mp3's as png's etc).

Let me know if I should send you the commit off-list or if you don't
mind enabling the attachment plugin for eg common image filetypes.

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


Re: [notmuch] Emacs paned UI

2010-02-03 Thread Jameson Rollins
On Mon, 01 Feb 2010 17:05:40 -0800, Tad Fisher tadfis...@gmail.com wrote:
 So, I dusted off my Elisp manual and hacked up notmuch.el to support a
 3-paned UI. This involved the creation of a minor mode (I call it
 notmuch-browse-mode) that manages window state, along with several
 modifications of existing functions to do the right thing when we're
 in browse-mode (such as close the show window, switch to the folder
 window, etc.).

Hey, Tad.  Thanks so much for persuing this!  I was definitely looking
to put something like this together myself, but your elisp foo is a lot
better than mine.  A couple comments:

* I actually would prefer just a two-paned layout, since I don't use
  folders.  Is there a way to configure it to check if there are folders
  defined, and not show the third panel if there isn't?

* I would also like to see the focus remain in the notmuch-search buffer
  all the time, unless I specifically switch to the notmuch-show
  buffer.  I would really like things to behave more like mutt, where
  I'm scrolling through my mail from notmuch-search, but then the
  messages themselves are just being displayed in the lower pane.  Does
  that make sense?

jamie.


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


Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread David Bremner
On Thu, 4 Feb 2010 09:18:29 +1300, martin f krafft madd...@madduck.net wrote:

 PS: speaking of prefixes, how about remving the subject prefix of
 this list in general? ;)

I used to agree, but in notmuch, I actually find it convenient to have
threads marked by mailing list. Perhaps this will change if/when my
email setup or the notmuch emacs ui get better...

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


Re: [notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread Jameson Rollins
On Thu, 4 Feb 2010 09:41:41 +1300, martin f krafft madd...@madduck.net wrote:
 also sprach David Bremner brem...@unb.ca [2010.02.04.0924 +1300]:
   PS: speaking of prefixes, how about remving the subject prefix of
   this list in general? ;)
  
  I used to agree, but in notmuch, I actually find it convenient to have
  threads marked by mailing list. Perhaps this will change if/when my
  email setup or the notmuch emacs ui get better...
 
 sed -e 's,^Subject:, [notmuch],'

I think I might agree with Martin.  The subject prefix doesn't really
seem necessary with notmuch, considering that for the following two
searches:

notmuch search to:notmuch@notmuchmail.org
notmuch search subject:[notmuch]

the first is actually more reliable for finding list messages.

jamie.


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


Re: [notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread David Bremner
On Wed, 03 Feb 2010 18:37:57 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 
 I think I might agree with Martin.  The subject prefix doesn't really
 seem necessary with notmuch, considering that for the following two
 searches:
 
 notmuch search to:notmuch@notmuchmail.org
 notmuch search subject:[notmuch]

Not to belabour the point, but I am talking about scanning my inbox
visually in emacs.

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


Re: [notmuch] Backport of Xapian term update optimisation

2010-02-03 Thread Olly Betts
On Wed, Feb 03, 2010 at 02:35:14PM -0500, Jameson Rollins wrote:
 On Thu, 28 Jan 2010 00:06:59 + (UTC), Olly Betts o...@survex.com wrote:
  I've backported the term update optimisation patches
  http://trac.xapian.org/ticket/250 to Xapian's 1.0 branch, and you can
  find snapshot tarballs including these changes here:
  
  http://oligarchy.co.uk/xapian/branches/1.0/
  
  Xapian's testsuite passes (including the additional test coverage which I
  also backported), and I looked over each change carefully, but I would be
  interested to see some real world testing, particularly in the situation
  which these changes are intended to improve (i.e. speed of tagging in
  notmuch).
 
 Hey, Olly.  Thanks so much for backporting this patch and uploading a
 patched package to Debian experimental (which is now available):

It hasn't built for all Debian architectures yet, but is available for at
least amd64 and x86, which are probably the most popular two.

If you aren't sure how to pull in packages from experimental, see:

http://wiki.debian.org/DebianExperimental

I've also put it in a Launchpad PPA for all currently supported Ubuntu
releases, which has built for all of them already:

https://launchpad.net/~ojwb/+archive/experimental/

 I just installed this new version from a Debian experimental repo,
 rebuilt notmuch against the new installation, and everything seems to be
 working great.  I'll report back any issues to the BTS.  Thanks again.

Thanks.  Are you seeing the expected speed improvement?

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


Re: [notmuch] Git feature branch

2010-02-03 Thread Carl Worth
On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft madd...@madduck.net wrote:
 I discussed this with Carl at LCA a bit and ideally we should come
 up with a way to relieve Carl of the bottleneck burden (obviously
 without stealing away his dictator hat ;)

Sounds great! Let's keep working together and find ways to help our
community work together. And I really appreciate all the help!

 I think it would make sense to move the mainline to git.debian.org
 for now, or another place where everyone can easily get an account.
 As alternatives I propose repo.or.cz. I'd prefer to stay away from
 commercial services like Github.

I'm glad to help make things work on notmuchmail.org directly. I don't
have a problem giving out shell access to people who want to help set
things up the way we want. (And prototyping things elsewhere is fine
too.)

 Once we're there, how about copying the branch structure from
 Git development[0]:
 
   maint/— the stable release
   master/   — the stablising head
   next/ — testing branch
   pu/   — patch integration branch (proposed updates)

I'm not a fan of this scheme, (or maybe I've just never quite understood
it).

When I first encountered this scheme, (when first using git), it was
never clear to me what branch I should actually run or test as a
user. Nor was it obvious which branches would be regularly rebased or
not---nor which branches had features being discussed on the mailing
list.

Here are some of my thoughts:

Instead of maint I'd much rather just have branches that are named
directly after the stable releases being maintained. We've done this
with the cairo repository with branch names like 1.2, 1.4, 1.6,
etc. That way it's very clear what the branch represents and it's
possible to have multiple concurrent live maintenance branches. But of
course, until we actually have releases, this doesn't really matter. :-)

I want to maintain a branch myself, (where I'm the only person pushing
to the branch). [This is different than what I've done with the cairo
repository where we have all core maintainer's pushing to a central
repository. I'm intentionally trying something new here.]

Obviously, that branch that I maintain is currently called master, but
I wouldn't mind (and might actually prefer) to have it be called
~cworth or so. Though we have the problem that we need master to
point to *something*.

Beyond that, I'm quite happy to have any number of branches similarly
maintained by any other individuals. I want to get things setup so that
those will be hosted and listed alongside my branch on
notmuchmail.org. And I'll be happy to accept pull requests from
people. I expect to find people naturally gravitating to ownership or
particular portions of the code, where I will gain a lot of trust for
particular maintainers over the code they own.

 What patch tracking workflow should we adopt? Keep sending patches
 to the mailing list

I definitely like the patches on the list. I find that with notmuch, I
can maintain a queue of outstanding patches very effectively, (meaning,
that the queue is usable and doesn't forget even if I do get very far
behind like I am currently).

 master or pu (or even maint/next), as appropriate? Use the Debian
 bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
 manager on notmuchmail.org? Use patchwork [1]?

I'm personally not interested in any system that requires me to push any
additional buttons outside of notmuch and git itself. I am interested in
tools that can generate reports and help provide visibility into
things. So patchwork fixed to automatically notice when patches are
merged would be interesting. Also interesting would be support for
publishing my notmuch-based queue of patches to a web page.

-Carl


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


Re: [notmuch] Git feature branch

2010-02-03 Thread Jameson Rollins
On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth cwo...@cworth.org wrote:
 I want to maintain a branch myself, (where I'm the only person pushing
 to the branch). [This is different than what I've done with the cairo
 repository where we have all core maintainer's pushing to a central
 repository. I'm intentionally trying something new here.]

Just my 2 cents here, but I fully support the idea of perusing a fully
distributed development model.  I have been using it on other projects I
work on and it works great.

 Obviously, that branch that I maintain is currently called master, but
 I wouldn't mind (and might actually prefer) to have it be called
 ~cworth or so. Though we have the problem that we need master to
 point to *something*.

There's really no need to do that.  For others developers, they would
just add your repo as a remote, which would presumably be named
something like cworth.  Then in the developers repo your master branch
would be named cworth/master.

With a crew of developers, A, B, C, etc., each one would add the others
as remotes, and their branches would be visible under their remotes, ie:

c...@host:~$ git branch -a
master
foo
bar
remotes/A/master
remotes/A/foo
remotes/B/master
remotes/B/foo
...

 Beyond that, I'm quite happy to have any number of branches similarly
 maintained by any other individuals. I want to get things setup so that
 those will be hosted and listed alongside my branch on
 notmuchmail.org. And I'll be happy to accept pull requests from
 people. I expect to find people naturally gravitating to ownership or
 particular portions of the code, where I will gain a lot of trust for
 particular maintainers over the code they own.

I think this is the right idea.

I think the problem we've been having recently is that we have bit of a
patch backlog due to circumstances of Carl's travel.  This is an issue
because the project is new and people are eager to see their
contributions in place.  I'm sure Carl will get to them as fast as he
can.  Once the project becomes more mature and other developers are
vetting patches, then their branches can take over as master in the
absence of an outdated canonical master.

jamie.


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


Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread Servilio Afre Puentes
On 3 February 2010 15:18, martin f krafft madd...@madduck.net wrote:
 also sprach Marten Veldthuis mar...@veldthuis.com [2010.02.04.0353 +1300]:
  Like this? http://notmuchmail.org/recentchanges/

 No, more like this: http://git.notmuchmail.org/git/notmuch-wiki

 To my knowledge, neither of these two give you diffs. This is what
 a post-receive hook offers.

In the second link, the links with the text commitdiff provide it,
and you have the Atom and RSS feeds at the bottom.

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


Re: [notmuch] list subject prefixes [was: Git commit mails (was: New wiki instance on the notmuchmail.org website)]

2010-02-03 Thread micah anderson
On Wed, 03 Feb 2010 18:37:57 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Thu, 4 Feb 2010 09:41:41 +1300, martin f krafft madd...@madduck.net 
 wrote:
  also sprach David Bremner brem...@unb.ca [2010.02.04.0924 +1300]:
PS: speaking of prefixes, how about remving the subject prefix of
this list in general? ;)
   
   I used to agree, but in notmuch, I actually find it convenient to have
   threads marked by mailing list. Perhaps this will change if/when my
   email setup or the notmuch emacs ui get better...
  
  sed -e 's,^Subject:, [notmuch],'
 
 I think I might agree with Martin.  The subject prefix doesn't really
 seem necessary with notmuch, considering that for the following two
 searches:
 
 notmuch search to:notmuch@notmuchmail.org
 notmuch search subject:[notmuch]

That is because xapian doesn't doesn't ount [] as words so doesn't index
them[0].

micah


0. according to kanru on IRC


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


Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread martin f krafft
also sprach Servilio Afre Puentes servi...@gmail.com [2010.02.04.1714 +1300]:
 In the second link, the links with the text commitdiff provide
 it, and you have the Atom and RSS feeds at the bottom.

As I see it, the feeds have links to the commitdiffs, but that's not
quite the same as having the diffs inline. You might be offline
without having pulled before, then the items from RSS/Atom are
useless.

If there is indeed an RSS/Atom feed on gitweb that includes the
diffs inline, please give me the URL; I can't fine ond.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
es ist immer etwas wahnsinn in der liebe.
 es ist aber auch immer etwas vernunft im wahnsinn.
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

2010-02-03 Thread martin f krafft
also sprach Servilio Afre Puentes servi...@gmail.com [2010.02.04.1918 +1300]:
  If there is indeed an RSS/Atom feed on gitweb that includes the
  diffs inline, please give me the URL; I can't fine ond.
 
 Can't see that even in the code.

Carl, could you set up notmuch-comm...@notmuchmail.org and enable
the commit and enable the mail hook as per

  http://notmuchmail.org/pipermail/notmuch/2010/001373.html

Sorry to burden you, but since you want to continue maintaining the
infrastructure, that's just what I have to do. ;)

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
beware of bugs in the above code;
i have only proved it correct, not tried it.
-- donald e. knuth
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch