Re: Provide an option to make thread summaries keep initial subject

Hi! Regarding the following ideas -- from almost a decade ago ;-) -- is anyone aware of any work in that area? On 2012-09-25T15:31:37-0400, Austin Clements wrote: > Quoth Olivier Berger on Sep 25 at 6:03 pm: >> Whenever a participant changes the subject in the middle of a thread, >> the

Re: notmuch vs. SIGPIPE

Hi! On 2020-01-20T23:36:51+0100, I wrote: > On 2020-01-20T12:55:28+0100, I wrote: >> While looking a bit into the item raised in >> id:87muamgspy@euler.schwinge.homeip.net I noticed the following >> (mis?)behavior by notmuch. >> >> To set the stage: >> >> $ yes | head -n 1 >> y >>

Re: notmuch vs. SIGPIPE

Hi! On 2020-01-20T12:55:28+0100, I wrote: > While looking a bit into the item raised in > id:87muamgspy@euler.schwinge.homeip.net I noticed the following > (mis?)behavior by notmuch. > > To set the stage: > > $ yes | head -n 1 > y > $ echo "${PIPESTATUS[@]}" > 141 0 > > As

notmuch vs. SIGPIPE

Hi! While looking a bit into the item raised in id:87muamgspy@euler.schwinge.homeip.net I noticed the following (mis?)behavior by notmuch. To set the stage: $ yes | head -n 1 y $ echo "${PIPESTATUS[@]}" 141 0 As expected, the 'yes' process exits with SIGPIPE right after the

Feature idea: Emacs 'notmuch-search' "paged" display

Hi! I had this following idea, but my Emacs foo is too limited to start implementing this -- if reasonably possible at all. Here is -- I suppose, not verified -- what happens if you do a command-line 'notmuch search [...] | less': the 'notmuch' process creates some output and the 'less' process

Transitioning notmuch/Xapian from 32-bit to 64-bit system

Hi! Suppose you have a huge notmuch/Xapian database, built on a 32-bit system (well, actually on x86_64-pc-linux-gnu, but using a years old 32-bit notmuch binary; notmuch 0.9, Xapian 1.2.21 -- don't laugh), and suppose you're finally going to update that years old notmuch installation (release by

header continuation issue in notmuch frontend/alot/pythons email module

Hi! On Mon, 24 Jun 2013 10:57:10 +0200, Justus Winter <4winter at informatik.uni-hamburg.de> wrote: > Quoting Austin Clements (2013-06-23 18:59:39) > > Quoth Justus Winter on Jun 23 at 3:11 pm: > > > I recently had a problem replying to a mail written by Thomas Schwin

Re: [PATCH] dump: Don't sort.

Hi! First, thanks to David, Tomi, Tom for moving this forward. On Sat, 19 Nov 2011 16:11:13 +0100, Petter Reinholdtsen p...@hungry.com wrote: [Thomas Schwinge] +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a measurement + * on a 372981 messages instance showed

[PATCH] dump: Don't sort.

Hi! First, thanks to David, Tomi, Tom for moving this forward. On Sat, 19 Nov 2011 16:11:13 +0100, Petter Reinholdtsen wrote: > [Thomas Schwinge] > > +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a > > measurement > > + * on a 372981 messages inst

[PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

Hi! On Thu, 10 Mar 2011 18:02:09 -0800, Carl Worth wrote: > On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge > wrote: > > This issue has been lying in ambush as of 2009-11-24's commit > > 93af7b574598637c2766dd1f8ef343962c9a8efb. > > Thanks very much for tracki

Google+ presence

Hi! I created a page on Google+ for notmuch: . Come in and say hello! Gr??e, Thomas -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not

Google+ presence

Hi! I created a page on Google+ for notmuch: https://plus.google.com/103455990805261371148. Come in and say hello! Grüße, Thomas pgpp536YbkJw6.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org

[PATCH] restore: Be more liberal in which data to accept.

From: Thomas Schwinge <tho...@schwinge.name> There are ``Message-ID''s out in the wild that contain spaces. --- Hi! Carl, the main question for you is: does this break sup-import operability? Spammers are quite inventive for creating ``interesting Messages-ID''s. Apparently, notmuch h

[PATCH] dump: Don't sort.

From: Thomas Schwinge <tho...@schwinge.name> This improves usage experience considerably in the given scenario. --- Hi! I decided that it'd be useful to put the reasoning and data right next to the source code (as opposed to putting it into the commit message), for the next guy t

[PATCH] dump: Don't sort.

From: Thomas Schwinge tho...@schwinge.name This improves usage experience considerably in the given scenario. --- Hi! I decided that it'd be useful to put the reasoning and data right next to the source code (as opposed to putting it into the commit message), for the next guy to read

[PATCH] restore: Be more liberal in which data to accept.

From: Thomas Schwinge tho...@schwinge.name There are ``Message-ID''s out in the wild that contain spaces. --- Hi! Carl, the main question for you is: does this break sup-import operability? Spammers are quite inventive for creating ``interesting Messages-ID''s. Apparently, notmuch handles

Austin's custom query parser: folder/directory searching, some numbers

Hi! As I already told on IRC (and which I still have to polish and publish...), I recently merged Austin's custom query parser into my local tree, mainly (for now) for its exact folder/directory searching capabilities. Austin had published this work several months ago, and Carl in the mean time

Austin's custom query parser: folder/directory searching, some numbers

Hi! As I already told on IRC (and which I still have to polish and publish...), I recently merged Austin's custom query parser into my local tree, mainly (for now) for its exact folder/directory searching capabilities. Austin had published this work several months ago, and Carl in the mean time

[PATCH] cli: change argument parsing convention for subcommands

Hi! On Fri, 21 Oct 2011 09:19:17 -0300, david at tethera.net wrote: > previously we deleted the subcommand name from argv before passing to > the subcommand. In this version, the deletion is done in the actual > subcommands. Although this causes some duplication of code, it allows > us to be more

Re: [PATCH] cli: change argument parsing convention for subcommands

Hi! On Fri, 21 Oct 2011 09:19:17 -0300, da...@tethera.net wrote: previously we deleted the subcommand name from argv before passing to the subcommand. In this version, the deletion is done in the actual subcommands. Although this causes some duplication of code, it allows us to be more

[PATCH v2] emacs: Turn id:"" elements into buttons for notmuch searches

Hi! On Mon, 17 Oct 2011 14:13:05 +0200, Daniel Schoepe wrote: > On Mon, 17 Oct 2011 11:16:45 +0200, Thomas Schwinge > wrote: > > Is it permissible for message IDs to contain double quotes? If not (and > > I hope so), might id:\"[^\"]+\" be a better regexp

[PATCH v2] emacs: Turn id:"" elements into buttons for notmuch searches

Hi! Good idea! On Wed, 6 Jul 2011 16:18:01 +0200, Daniel Schoepe wrote: > +(defun notmuch-show-buttonise-links (start end) > + "Buttonise URLs and mail addresses between START and END. > + > +This also turns id:\"\"-parts into buttons for > +a corresponding notmuch search." > +

Re: [PATCH v2] emacs: Turn id:message-id elements into buttons for notmuch searches

Hi! Good idea! On Wed, 6 Jul 2011 16:18:01 +0200, Daniel Schoepe daniel.scho...@googlemail.com wrote: +(defun notmuch-show-buttonise-links (start end) + Buttonise URLs and mail addresses between START and END. + +This also turns id:\message id\-parts into buttons for +a corresponding

Re: [PATCH v2] emacs: Turn id:message-id elements into buttons for notmuch searches

Hi! On Mon, 17 Oct 2011 14:13:05 +0200, Daniel Schoepe daniel.scho...@googlemail.com wrote: On Mon, 17 Oct 2011 11:16:45 +0200, Thomas Schwinge tho...@schwinge.name wrote: Is it permissible for message IDs to contain double quotes? If not (and I hope so), might id:\[^\]+\ be a better

[no subject]

Hi! On Mon, 10 Oct 2011 10:49:15 -0300, david at tethera.net wrote: > OK, here is my proposal to add search terms to notmuch dump. Having worked in the same area ;-), I felt competent to review this. And I definitely do like David's approach. The patches look good, with the following comments:

[python] set rpath in setup.cfg

Hi! On Wed, 12 Oct 2011 23:34:28 -0700, Jameson Graef Rollins wrote: > On Thu, 13 Oct 2011 08:12:03 +0200, dtk wrote: > > in my experience, it tends to cause awkward side effects that are hard to > > debug, the main problem being that it overrides all default paths and is > > hard to target at

Re:

Hi! On Mon, 10 Oct 2011 10:49:15 -0300, da...@tethera.net wrote: OK, here is my proposal to add search terms to notmuch dump. Having worked in the same area ;-), I felt competent to review this. And I definitely do like David's approach. The patches look good, with the following comments:

[PATCH] emacs: Modify notmuch-show-get-message-id to return message-id unprefixed with "id:".

Hi! On Sun, 9 Oct 2011 15:35:48 -0700, Jameson Graef Rollins wrote: > (defun notmuch-show-get-message-id () >"Return the message id of the current message." > - (concat "id:\"" (notmuch-show-get-prop :id) "\"")) > + (concat "\"" (notmuch-show-get-prop :id) "\"")) Shouldn't the double

Re: [PATCH] NEWS: add notes about emacs improvements and reply formating cleanup

Hi! On Sat, 08 Oct 2011 20:55:59 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Ok, I just realized why these messages aren't showing up in reply to the messages I intend: it's the id: prefix that's there when I use c i to copy the message ID to the kill-ring! I'm then

Re: [PATCH] emacs: Modify notmuch-show-get-message-id to return message-id unprefixed with id:.

Hi! On Sun, 9 Oct 2011 15:35:48 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: (defun notmuch-show-get-message-id () Return the message id of the current message. - (concat id:\ (notmuch-show-get-prop :id) \)) + (concat \ (notmuch-show-get-prop :id) \)) Shouldn't the

[PATCH] NEWS: add notes about emacs improvements and reply formating cleanup

Hi! On Sat, 08 Oct 2011 20:55:59 -0700, Jameson Graef Rollins wrote: > Ok, I just realized why these messages aren't showing up in reply to the > messages I intend: it's the "id:" prefix that's there when I use "c i" > to copy the message ID to the kill-ring! I'm then in-reply-to'ing > >

[PATCH] emacs: Add callback functions to crypto sigstatus button.

Hi! On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins wrote: > This adds two callback functions to the sigstatus button. If the sig First, thanks for this! > status is "good", then clicking the button displays the output of "gpg > --list-keys" on the key fingerprint. If the sigstatus

Re: [PATCH] emacs: Add callback functions to crypto sigstatus button.

Hi! On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: This adds two callback functions to the sigstatus button. If the sig First, thanks for this! status is good, then clicking the button displays the output of gpg --list-keys on the key

[PATCH] patchformatting: Test Suite Enhancements

Based on the emails starting at id:"87liu2kcq6.fsf at servo.factory.finestructure.net". --- Hi! I applied the attached patch, based on this thread's discussion. Gr??e, Thomas --- patchformatting.mdwn | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git

[PATCH, v2] notmuch restore --accumulate

From: Thomas Schwinge <tho...@schwinge.name> The --accumulate switch causes the union of the existing and new tags to be applied, instead of replacing each message's tags as they are read in from the dump file. --- Hi! Beware that I have not yet used this new functionality in th

[PATCH, v2] notmuch restore --accumulate

From: Thomas Schwinge <tho...@schwinge.name> Flesh out what ``notmuch restore --accumulate'' is supposed to do. Its tests are currently XFAILed; the functionality will be added in another patch. Also generally enhance the dump-restore testsuite, and make it more failure-proof. --- tes

[PATCH, v2] notmuch restore --accumulate

From: Thomas Schwinge tho...@schwinge.name Flesh out what ``notmuch restore --accumulate'' is supposed to do. Its tests are currently XFAILed; the functionality will be added in another patch. Also generally enhance the dump-restore testsuite, and make it more failure-proof. --- test/dump

[PATCH, v2] notmuch restore --accumulate

From: Thomas Schwinge tho...@schwinge.name The --accumulate switch causes the union of the existing and new tags to be applied, instead of replacing each message's tags as they are read in from the dump file. --- Hi! Beware that I have not yet used this new functionality in the wild

[PATCH] patchformatting: Test Suite Enhancements

Based on the emails starting at id:87liu2kcq6@servo.factory.finestructure.net. --- Hi! I applied the attached patch, based on this thread's discussion. Grüße, Thomas --- patchformatting.mdwn | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git

[PATCH] Repeatability when copying a whole directory into a new one.

This new test currently fails -- but it shouldn't. --- Hi! I found this while manually copying directories and running notmuch new. Am I just too sleepy at this time, or is it another DB vs. directory mtime issue? BROKEN Repeatability when copying a whole directory into a new one

[PATCH] notmuch restore --accumulate

Hi! On Fri, 9 Sep 2011 12:13:06 -0400, Austin Clements wrote: > The idea behind sending the test first is that people can see that it fails > and that the subsequent patch indeed fixes it. What I find works well is to > submit the test case with the test marked as broken and then the main

[PATCH] notmuch restore --accumulate

Hi! On Fri, 9 Sep 2011 11:06:34 +0200, Louis Rilling wrote: > On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote: > > Also, we generally prefer to have modifications to the test suite in > > separate patches that precede the patches that add the features/fix the > > bugs. > > > > For new

Re: [PATCH] notmuch restore --accumulate

Hi! On Fri, 9 Sep 2011 11:06:34 +0200, Louis Rilling l.rill...@av7.net wrote: On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote: Also, we generally prefer to have modifications to the test suite in separate patches that precede the patches that add the features/fix the bugs. For

[PATCH] notmuch restore --accumulate

From: Thomas Schwinge <tho...@schwinge.name> Also enhance the dump-restore testsuite, and make it generally more failure-proof. Signed-off-by: Thomas Schwinge --- Hi! Beware that I have not yet used this new functionality in the wild. ;-) (But I do plan to do so, soon.) And, I

Build system

Hallo! On Sun, 30 Jan 2011 21:14:39 +1000, Carl Worth wrote: > On Sun, 30 Jan 2011 11:28:08 +0100, Thomas Schwinge > wrote: > > Still, my point holds that (unless someone is willing to spend time on > > this, of course) we shouldn't try to replicate the Autotools, but in

Re: Build system

Hallo! On Sun, 30 Jan 2011 21:14:39 +1000, Carl Worth cwo...@cworth.org wrote: On Sun, 30 Jan 2011 11:28:08 +0100, Thomas Schwinge tho...@schwinge.name wrote: Still, my point holds that (unless someone is willing to spend time on this, of course) we shouldn't try to replicate the Autotools

[PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

Hallo! On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements wrote: > Is there a reason you keep the remaining data in a string instead of > taking the more idiomatic elisp approach of leaving it in the process > buffer? In fact, the code would probably be simpler if you > immediately appended the

[PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

This issue has been lying in ambush as of 2009-11-24's commit 93af7b574598637c2766dd1f8ef343962c9a8efb. Signed-off-by: Thomas Schwinge --- emacs/notmuch.el | 70 +++-- 1 files changed, 41 insertions(+), 29 deletions(-) diff --git a/emacs

[PATCH 1/2] New test: Emacs' forgetfulness.

Signed-off-by: Thomas Schwinge --- test/emacs-forgetfulness | 38 ++ test/notmuch-test|1 + 2 files changed, 39 insertions(+), 0 deletions(-) create mode 100755 test/emacs-forgetfulness diff --git a/test/emacs-forgetfulness b/test/emacs

[BUG] Emacs UI dropping every 25th line, roughly

t; > 16:26:57.928798 read(8, "[first two dozen results]" > "thread:000006c7 2009-12-16 [2/2] > Thomas Schwinge; [subject] ([flags])\n" > "t", 4096) = 4095 > > The l

[PATCH] Shell programming: directories are ``executable'' (that is, searchable), too.

Signed-off-by: Thomas Schwinge tho...@schwinge.name --- test/test-lib.sh |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index f536172..3471ead 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -815,13 +815,14 @@ EOF

[PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

This issue has been lying in ambush as of 2009-11-24's commit 93af7b574598637c2766dd1f8ef343962c9a8efb. Signed-off-by: Thomas Schwinge tho...@schwinge.name --- emacs/notmuch.el | 70 +++-- 1 files changed, 41 insertions(+), 29 deletions(-) diff

Re: [BUG] Emacs UI dropping every 25th line, roughly

:57.928798 read(8, [first two dozen results] thread:06c7 2009-12-16 [2/2] Thomas Schwinge; [subject] ([flags])\n t, 4096) = 4095 The last result line is obviously incomplete, only the `t' so far. notmuch.el:notmuch-search

Re: [PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

Hallo! On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements amdra...@mit.edu wrote: Is there a reason you keep the remaining data in a string instead of taking the more idiomatic elisp approach of leaving it in the process buffer? In fact, the code would probably be simpler if you immediately

[PATCH] Shell programming: directories are ``executable'' (that is, searchable), too.

Signed-off-by: Thomas Schwinge --- test/test-lib.sh |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index f536172..3471ead 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -815,13 +815,14 @@ EOF } +# Locate the directory

[BUG] Emacs UI dropping every 25th line, roughly

The log: [some write()s for the first two dozen search results] 16:26:54.143464 write(1, "thread:000006c7 2009-12-16 [2/2] Thomas Schwinge; [subject] ([flags])\n", 135) = 135 [...] 16:26:54.266866 write(1, "thread:0ac4 2009-12-16 [1/1] jsm28 a

[PATCH 4/4] ruby: Add generated files to gitignore

Hallo! On Mon, 10 Jan 2011 16:39:28 +0200, Ali Polatel wrote: > --- a/.gitignore > +++ b/.gitignore > @@ -13,3 +13,7 @@ libnotmuch.so* > .*.swp > *.elc > releases > + > +bindings/ruby/mkmf.log > +bindings/ruby/notmuch.so > +bindings/ruby/Makefile These should rather be put into

Re: [PATCH 4/4] ruby: Add generated files to gitignore

Hallo! On Mon, 10 Jan 2011 16:39:28 +0200, Ali Polatel a...@exherbo.org wrote: --- a/.gitignore +++ b/.gitignore @@ -13,3 +13,7 @@ libnotmuch.so* .*.swp *.elc releases + +bindings/ruby/mkmf.log +bindings/ruby/notmuch.so +bindings/ruby/Makefile These should rather be put into

[BUG] Emacs UI dropping every 25th line, roughly

Hallo! I noticed this one on a system with my work emails (which is what I recently reported on the IRC channel), but can reproduce it on another system, too. :-/ The first system is using Ubuntu's emacs23 23.1+1-4ubuntu7.1+maverick1, the other Debian's emacs23 23.2+1-7. In the Emacs UI, do a

[PATCH] Add a few tests for searching LWN emails.

Hallo! On Sat, 29 Jan 2011 05:59:38 +1000, Carl Worth wrote: > On Thu, 27 Jan 2011 03:31:49 -0700, Thomas Schwinge > wrote: > > These tests should pass -- but they currently don't. > Thanks for sending these test cases. This is actually my favorite way to > receive bug

[PATCH] Add a few tests for searching LWN emails.

Hallo! On Sat, 29 Jan 2011 14:45:19 +0100, Matthieu Lemerre wrote: > I had already reported this problem in id:"87ipzvk2xh.fsf at free.fr". Oh, I see! > Recent versions of GMime perform more robust parsing that fix the > problem, but unfortunately debian only ship old versions of the package.

Build system

Hallo! On Sun, 30 Jan 2011 11:12:42 +0100, I wrote: > On Sat, 29 Jan 2011 06:58:59 +1000, Carl Worth wrote: > > Rather than documenting a limitation here, why don't we do what people > > actually want. > > Well, not a big deal for me -- I'm just used to building projects > containing a

Build system (was: [PATCH] Have to configure and build inside the source directory.)

Hallo! On Sat, 29 Jan 2011 06:58:59 +1000, Carl Worth wrote: > Rather than documenting a limitation here, why don't we do what people > actually want. Well, not a big deal for me -- I'm just used to building projects containing a configure file outside of the source tree, and the notmuch build

Build system (was: [PATCH] Have to configure and build inside the source directory.)

Hallo! On Sat, 29 Jan 2011 06:58:59 +1000, Carl Worth cwo...@cworth.org wrote: Rather than documenting a limitation here, why don't we do what people actually want. Well, not a big deal for me -- I'm just used to building projects containing a configure file outside of the source tree, and the

Re: Build system

Hallo! On Sun, 30 Jan 2011 11:12:42 +0100, I tho...@schwinge.name wrote: On Sat, 29 Jan 2011 06:58:59 +1000, Carl Worth cwo...@cworth.org wrote: Rather than documenting a limitation here, why don't we do what people actually want. Well, not a big deal for me -- I'm just used to building

Re: [PATCH] Add a few tests for searching LWN emails.

Hallo! On Sat, 29 Jan 2011 14:45:19 +0100, Matthieu Lemerre ra...@free.fr wrote: I had already reported this problem in id:87ipzvk2xh@free.fr. Oh, I see! Recent versions of GMime perform more robust parsing that fix the problem, but unfortunately debian only ship old versions of the

[BUG] Emacs UI dropping every 25th line, roughly

Hallo! I noticed this one on a system with my work emails (which is what I recently reported on the IRC channel), but can reproduce it on another system, too. :-/ The first system is using Ubuntu's emacs23 23.1+1-4ubuntu7.1+maverick1, the other Debian's emacs23 23.2+1-7. In the Emacs UI, do a

notmuch's idea of concurrency / failing an invocation

Hallo! On Fri, 28 Jan 2011 15:10:01 +1000, Carl Worth wrote: > On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements > wrote: > > I'm looking into breaking notmuch new up into small transactions. It > > wouldn't be much a leap from there to simply close and reopen the database > > between

[PATCH] Clarify usage of `additional_headers' in test/test-lib.sh:generate_message.

Hallo! On Fri, 28 Jan 2011 15:36:25 +1000, Carl Worth wrote: > On Thu, 27 Jan 2011 02:17:21 -0700, Thomas Schwinge > wrote: > > +# Note that in the way we're setting it above and using it below, > > +# `additional_headers' will also serve as the heade

notmuch's idea of concurrency / failing an invocation

Hallo! Stepping away from the current code base -- what is notmuch's original idea of concurrency? That is, all of us probably know that one: A Xapian exception occurred opening database: Unable to get write lock on /home/thomas/Mail-schwinge.name-thomas/.notmuch/xapian: already

[PATCH] Add a few tests for searching LWN emails.

These tests should pass -- but they currently don't. Signed-off-by: Thomas Schwinge --- Hallo! I reported this on IRC some weeks ago; here is a more elaborate report. What we get from these emails, is an author named ``LWN.net'', and the ``Weekly Notification'' / ``Mailing Lists'' bits

[PATCH] Clarify usage of `additional_headers' in test/test-lib.sh:generate_message.

Signed-off-by: Thomas Schwinge --- test/test-lib.sh |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index d179426..f536172 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -351,8 +351,11 @@ ${additional_headers

notmuch's idea of concurrency / failing an invocation

Hallo! Stepping away from the current code base -- what is notmuch's original idea of concurrency? That is, all of us probably know that one: A Xapian exception occurred opening database: Unable to get write lock on /home/thomas/Mail-schwinge.name-thomas/.notmuch/xapian: already

Re: [PATCH] Clarify usage of `additional_headers' in test/test-lib.sh:generate_message.

Hallo! On Fri, 28 Jan 2011 15:36:25 +1000, Carl Worth cwo...@cworth.org wrote: On Thu, 27 Jan 2011 02:17:21 -0700, Thomas Schwinge tho...@schwinge.name wrote: +# Note that in the way we're setting it above and using it below, +# `additional_headers' will also serve as the header

[PATCH 2/3] new: Add all initial tags at once

Hallo! On Fri, 21 Jan 2011 10:59:36 +0100, Michal Sojka wrote: > --- a/notmuch-new.c > +++ b/notmuch-new.c > @@ -418,6 +418,7 @@ add_files_recursive (notmuch_database_t *notmuch, > /* success */ > case NOTMUCH_STATUS_SUCCESS: > state->added_messages++; > +

bug tracking

Hallo! On Mon, 03 May 2010 15:32:09 -0400, Jesse Rosenthal wrote: > Well, this is as good a time to make an announcement as any. I have a > prototype, nm-remote, in its early stages available here: > > git clone http://jkr.acm.jhu.edu/git/nm-remote.git I wanted to have a look at this, but the

Re: bug tracking

Hallo! On Mon, 03 May 2010 15:32:09 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: Well, this is as good a time to make an announcement as any. I have a prototype, nm-remote, in its early stages available here: git clone http://jkr.acm.jhu.edu/git/nm-remote.git I wanted to have a look at

[PATCH] Properly quote Emacs' notmuch-command.

From: Thomas Schwinge <thomas_schwi...@mentor.com> It happens that my notmuch-command may look like this: (setq notmuch-command "~/Mentor Graphics/command/notmuch") Most of the times, notmuch-command is passed to call-process which will simply do the right thing, but there

[ANN] notmuch-deliver

Hallo! On Mon, 08 Nov 2010 09:50:46 -0800, Carl Worth wrote: > On Wed, 26 May 2010 17:01:34 +0300, Ali Polatel wrote: > > notmuch-deliver is a maildir delivery tool for notmuch mail indexer. It > > reads from standard input, delivers the mail to the specified maildir > > and adds it to the

[PATCH] Have to configure and build inside the source directory.

From: Thomas Schwinge tho...@schwinge.name Signed-off-by: Thomas Schwinge tho...@schwinge.name --- configure | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/configure b/configure index c58dd0f..b5e446c 100755 --- a/configure +++ b/configure @@ -188,6 +188,17

Hallo!, and hooray!, and some first work, too

Hallo! After having read about it in ..., in ..., (don't know anymore), and then again over at LWN, I have had the plan to try (or rather: directly switch to) notmuch like half a year ago, or longer. I eventually was brave enough to begin that process in the last days of 2010. I'm still with