[notmuch] Some thoughts about notmuch sync with other agents

Hi, before going into details, I'd like to tell you how much I like the notmuch workflow, thank you for producing this nice piece of software ! Like most potential users, I can not really fully jump into notmuch because of the current synchronisation issues with others MUA. One may or may not

[notmuch] Git feature branch

is designed to do, and it actually works really well. 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/20100127/fcded64c/attachment.pgp>

[notmuch] Git feature branch

Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010: > On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote: > > > 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

[notmuch] Indexing without files and directories

Hi all, I don't want to throw a spanner in the works, but I am intending to use notmuch for indexing in a scenario where the email doesn't hit the disk - the notmuch model seems to rely pretty heavily on directories and files but I'm working with email being delivered to a script for

[notmuch] Git feature branch

up, patch queue trackers or patchwork to have anything to say about those. 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/20100127/297ea735/attachment.pgp>

[notmuch] Internal error no thread ID

Hello, I have tried to add some mails to the index with "notmuch new" but it gives me: Internal error: Message with document ID of 62004 has no thread ID. (lib/message.cc:353). Is it possible to get the filename for the document 62004? Is there any way to exclude some files from indexing? I

[notmuch] [PATCH] Make the date parser nicer

On Tue, 26 Jan 2010 09:55:00 -0800, Keith Packard wrote: > Very cool. Oh, if you've got commits that don't compile on their own, > you should squash them together (or fix it in some other way). Makes > bisecting easier in the future. Makes sense. I am still quite new to git, so excuse those

[notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth" wrote: > While notmuchsync fullfils my needs, it is a kludge. It needs to call > "notmuch" for each mail where a MailDir flag has changed (which can be > quite often on an initial run, where most mails are likely to be read), > this can take

[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code

much helper scripts, hopefully including notmuchsync. 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

Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail)

On Mon, 25 Jan 2010 14:49:00 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: While notmuchsync fullfils my needs, it is a kludge. It needs to call notmuch for each mail where a MailDir flag has changed (which can be quite often on an initial run, where most mails are likely to be read),

Re: [notmuch] [PATCH] Make the date parser nicer

On Tue, 26 Jan 2010 09:55:00 -0800, Keith Packard kei...@keithp.com wrote: Very cool. Oh, if you've got commits that don't compile on their own, you should squash them together (or fix it in some other way). Makes bisecting easier in the future. Makes sense. I am still quite new to git, so

[notmuch] Internal error no thread ID

Hello, I have tried to add some mails to the index with notmuch new but it gives me: Internal error: Message with document ID of 62004 has no thread ID. (lib/message.cc:353). Is it possible to get the filename for the document 62004? Is there any way to exclude some files from indexing? I

[notmuch] Indexing without files and directories

Hi all, I don't want to throw a spanner in the works, but I am intending to use notmuch for indexing in a scenario where the email doesn't hit the disk - the notmuch model seems to rely pretty heavily on directories and files but I'm working with email being delivered to a script for

Re: [notmuch] [patch] store folder information

Hi Andreas, I'm just writing because of the patch you sent to the notmuch list on December 15th. It seems like many people are wanting this functionality, I know I am myself and Carl has also indicated the same. However, there were a couple of minor suggestions for improvements for your patch

Re: [notmuch] Git feature branch

Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010: On Mon, 25 Jan 2010 16:46:43 -0800, sebast...@sspaeth.de wrote: 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

Re: [notmuch] Git feature branch

also sprach micah anderson mi...@riseup.net [2010.01.27.1124 +1300]: Couldn't all of this be done without moving the existing git repository (don't forget that transition is a cost)? Those who wish to put together these proposed branches go ahead and do so, publishing those wherever they like

[notmuch] Backport of Xapian term update optimisation

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

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins jroll...@finestructure.net [2010.01.26.1046 +1300]: For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603 +1300]: This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? I think this idea is

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft madd...@madduck.net wrote: also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603 +1300]: This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]: Are you trying to use thread: such that it could be passed to notmuch show to see the conversation? That's not going to work so well if so. Why not? Works fine for me with the vim plugin... -- martin |

[notmuch] Fwd: Re: [patch] store folder information

As instructed by Micah below, I'm hereby letting the list know I'm no longer interesting in shepherding that patch. Best, Andreas -- Forwarded Message -- Betreff: Re: [notmuch] [patch] store folder information Datum: Mittwoch 27 Januar 2010 Von: micah anderson mi...@riseup.net

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

On Thu, 28 Jan 2010 18:34:21 +1300, martin f krafft madd...@madduck.net wrote: also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]: Are you trying to use thread: such that it could be passed to notmuch show to see the conversation? That's not going to work so well

Re: [notmuch] Git feature branch

* martin f krafft (madd...@madduck.net) wrote: also sprach micah anderson mi...@riseup.net [2010.01.27.1124 +1300]: Personally, I've found mailing lists that have patches sent to them tends to totally kill the list for anything else. It seems a bit weird to use Debian's bug tracker for a