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

2010-01-28 Thread martin f krafft
also sprach martin f krafft  [2010.01.28.1834 +1300]:
> > That's not going to work so well if so.
> 
> Why not? Works fine for me with the vim plugin...

Now I get it. I was talking about
id:20100114084713.GA22273 at harikalardiyari

Sorry, I *am* new to notmuch ;)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"when zarathustra was alone... he said to his heart: 'could it be
 possible! this old saint in the forest hath not yet heard of it, that
 god is dead!'"
 - friedrich nietzsche

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/c2bedb2b/attachment.pgp>


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

2010-01-28 Thread Jed Brown
On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari  wrote:
> Sounds like you need to add a line to crontab.

I haven't been following this thread closely so I hope this isn't too
out of context.  I agree that certain things like notmuch-new should go
in the crontab, but I think that notmuch-new should need to be run
exactly once to process a new batch of messages into the desired state.

Having notmuch-new apply one set of tags and then relying on another
process run afterwards to change the tags according to a filter is
undesirable in my opinion, both for the mild performance reason of
making two passes, but more importantly because of lock contention
between the two processes and the ease of viewing the database in the
inconsistent state.  As far as I understand the situation, my favorite
solution is to have notmuch-new run a hook on each message as it is
indexed.

Jed


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

2010-01-28 Thread Ben Gamari
Excerpts from martin f krafft's message of Thu Jan 28 17:17:35 -0500 2010:
> Cron-scheduling is a regular activity. I am talking about
> event-based scheduling. incron could do that and fire up a process
> every time a message is dropped into a directory, but notmuch
> doesn't provide me with an interface to say "you don't have to
> iterate the Maildir yourself since I know exactly what changed: just
> update your catalog with the new message in file foo/bar.msg".

Fair enough. After reading your arguments I think I might have initially
misunderstood you. I would actually tend to agree. Passing
paths to notmuch does seem to be a reasonable approach.

> 
> To me, notmuch-new is not Unix-y. To me,
> 
>   find $MAILDIR -type f -print0 | xargs -0 notmuch-update
> 
> is Unix-y. ;)
> 
I think it really depends upon what you are doing. I can certainly see
when you might be want to simply have notmuch synchronize the index
against the mail store. However, it seems the majority of the time one
simply desires to add a message to the index (i.e. after delivery).
Therefore, it seems like there is a place for both commands.

> > In my configuration, I simply have a bash script in ~/.bin that simply
> > runs offlineimap followed by notmuch new. This works quite nicely.
> 
> This is essentially the same situation as with slocate, which has to
> be run from cron currently, and hence gets outdated regularly.
> Compare this to a hypothetical filesystem that exposed an index of
> filenames (or content even!) to user-space, which could be used to
> quickly search for files in real-time without the need to run
> regular updates. I know other operating systems that have this
> functionality already.
> 
> Anyway, this is going off on a tangent, I feel.
> 
That might be true but that certainly won't stop. ;) One would think
that it wouldn't be difficult to teach slocate about inotify. I briefly
looked into this and found rlocate but quickly realized that it requires
its own kernel module. Apparently this has been investigated[1] and
the inotify watch count limit becomes an issue very quickly. I seem to
recall, however, that there were some whispers on the LKML about adding
an interface that would be more capable of supporting such a system. I
can't seem to recall the details, however, and homework beckons.

Cheers,

- Ben


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

2010-01-28 Thread James Westby
On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft  
wrote:
> also sprach Jameson Rollins  [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 completely independent of anything having to do
> > with using git as a mail store.  That's why I was trying to separate it
> > into a separate thread.
> 
> I think he meant "notmuch hooks like you have hooks for Git too",
> e.g. thread:755741d13573c7642761d2a175cb146d

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.

Thanks,

James


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

2010-01-28 Thread martin f krafft
also sprach Jameson Rollins  [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 completely independent of anything having to do
> with using git as a mail store.  That's why I was trying to separate it
> into a separate thread.

I think he meant "notmuch hooks like you have hooks for Git too",
e.g. thread:755741d13573c7642761d2a175cb146d

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"if i am occasionally a little overdressed, i make up for it by being
 always immensely over-educated."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/2ace6379/attachment.pgp>


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

2010-01-28 Thread martin f krafft
also sprach Jameson Rollins  [2010.01.26.1046 
+1300]:
> > For example, I might have:
> > 
> > ~/.notmuch-config:
> > 
> > [database]
> > path=/home/pioto/mail
> > ...
> > [tags]
> > pioto at pioto.org/INBOX.ListMail.notmuch = notmuch
> > 
> > So, a 'tags' section, where each key is the folder name, relative to the
> > db path, and the value is one or more tag names
> 
> I think this idea is a really good one and I would like to pursue it as
> a tangent thread here.  I was going to propose something very similar to
> this.  I think it's a very flexible idea that would help in a lot of
> ways.

I think we need to carefully distinguish here. The above seems to
suggest a mapping from folder to tag, but we don't actually need
tags for folder locations, because those can (and should) be
implicitly determined from the database and storing the tag in
addition would just run the risk of getting out of sync: if I moved
a message, I would also have to remember to delete old and add new
tags, which is just asking for trouble.

> [tags]
> inbox = +inbox,+unread
> sent = +sent
> drafts = +draft
> archive = -inbox

This proposal, on the other hand, is an interesting one, but when is
it supposed to happen? It just feels wrong to make this happen as
part of 'notmuch new'.

What I would like to see is a notmuch-aware MDA, e.g. a programme
which reads an incoming mail on stdin and can do all this kind of
stuff, e.g. assign tags based on such rules (or take tags as
arguments, so that I could trivially set tags from procmail too),
write the message to the message store, and update the database.

This would allow us to get rid of 'notmuch new' altogether, at least
conceptually. We'd still need it if mail is being delivered
independently, e.g. with offlineimap.

On the performance side, it might make sense to write to a journal
instead of updating the database every time. SpamAssassin does this
with its Bayesian database, and it only merges the journal every
X updates (or when the user manually requests it). I am not sure
whether this is possible with Xapian. On the other hand, I think
notmuch needs to learn to journal anyway so that we can keep
different instances in sync.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"the only way to get rid of a temptation is to yield to it."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/d544bd5e/attachment.pgp>


[notmuch] [PATCH 2/2] Preserve folder information when indexing

2010-01-28 Thread Michal Sojka
This patch was originally sent by Andreas Kl?ckner. This is a slightly
reworked version (only coding style changes) which was manually rebased
to the current HEAD.

There are still things to fix (see the previous Carl's email)
- Redundant trailing directory name traversal
- Supporting hierarchical folders
---
 lib/database.cc |   13 +
 lib/notmuch.h   |1 +
 notmuch-new.c   |   38 +-
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index cce7847..5f2f35d 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
  * MESSAGE_ID: The unique ID of the mail mess (see "id" above)
  *
  * In addition, terms from the content of the message are added with
- * "from", "to", "attachment", and "subject" prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * "from", "to", "attachment", "subject" and "folder" prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
  *
  * The data portion of a mail document is empty.
  *
@@ -154,7 +154,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { "from",  "XFROM" },
 { "to","XTO" },
 { "attachment","XATTACHMENT" },
-{ "subject",   "XSUBJECT"}
+{ "subject",   "XSUBJECT"},
+{ "folder","XFOLDER"}
 };

 int
@@ -1317,6 +1318,7 @@ _notmuch_database_link_message (notmuch_database_t 
*notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1432,6 +1434,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);

+   if (folder_name != NULL)
+   _notmuch_message_gen_terms (message, "folder", folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 15c9db4..3a5ab78 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -263,6 +263,7 @@ notmuch_database_get_directory (notmuch_database_t 
*database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message);

 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..b7c65db 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include "notmuch-client.h"

 #include 
+#include 

 typedef struct _filename_node {
 char *filename;
@@ -169,6 +170,35 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 return 0;
 }

+static char*
+_get_folder_base_name(const char *path)
+{
+gchar *full_folder_name = NULL;
+gchar *folder_base_name = NULL;
+
+/* Find name of "folder" containing the email. */
+full_folder_name = g_strdup(path);
+while (1) {
+   folder_base_name = g_path_get_basename(full_folder_name);
+
+   if (strcmp(folder_base_name, "cur") == 0
+   || strcmp(folder_base_name, "new") == 0) {
+   gchar *parent_name = g_path_get_dirname(full_folder_name);
+   g_free(full_folder_name);
+   full_folder_name = parent_name;
+   } else
+   break;
+}
+
+g_free(full_folder_name);
+
+if (strcmp(folder_base_name, ".") == 0) {
+   g_free(folder_base_name);
+   folder_base_name = NULL;
+}
+return folder_base_name;
+}
+
 /* Examine 'path' recursively as follows:
  *
  *   o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -222,6 +252,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 notmuch_filenames_t *db_subdirs = NULL;
 struct stat st;
 notmuch_bool_t is_maildir, new_directory;
+char *folder_base_name = NULL;

 if (stat (path, )) {
fprintf (stderr, "Error reading directory %s: %s\n",
@@ -407,7 +438,10 @@ add_files_recursive (notmuch_database_t *notmuch,
fflush (stdout);
}

-   status = notmuch_database_add_message (notmuch, next, );
+   folder_base_name = _get_folder_base_name(path);
+   status = notmuch_database_add_message (notmuch, next,
+  folder_base_name,
+  );
switch (status) {
/* success */
case NOTMUCH_STATUS_SUCCESS:
@@ -499,6 +533,8 @@ add_files_recursive (notmuch_database_t *notmuch,

[notmuch] [PATCH 1/2] Skip German "aw:" prefix in subjects

2010-01-28 Thread Michal Sojka
This was originally present in Andreas Kl?ckner's patch.
---
 lib/index.cc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/index.cc b/lib/index.cc
index 7e2da08..eb97f91 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
s++;
if (strncasecmp (s, "re:", 3) == 0)
s += 3;
+else if (strncasecmp (s, "aw:", 3) == 0)
+   s += 3;
else
break;
 }
-- 
1.6.6



[notmuch] [patch] store folder information

2010-01-28 Thread Michal Sojka
On Wednesday 27 of January 2010 16:55:55 micah anderson wrote:
> have not seen a reply from you yet. I'm particularly eager to see this
> get accepted upstream, and it sounds like the changes necessary to do so
> are relatively minor.

Hi Micah and others,

I wanted to test this patch, so I rebased it to the current HEAD. I had to do 
it manually since notmuch evolved significantly since the original posting. 
I'll post in followup mails.

> I'm wondering what your plans are for addressing these issues? I've come
> to depend on this functionality, and would love to see it incorporated
> upstream!
> 
> Specifically these were:
> 
> 1. Unrelated whitespace:

Fixed.

> 2. An unrelated hunk creeping in:
> 
> On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> > On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner
> >  
> tiker.net> wrote:
> > > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > >   s++;
> > >   if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > >   s +=3D 3;
> > > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > > + s +=3D 3;
> > >   else
> > >   break;
> > >  }

Fixed.

> 3. Redundant trailing directory name traversal:
> > > +gchar *full_folder_name =3D NULL;
> > > +gchar *folder_base_name =3D NULL;
> > > +
> > > +/* Find name of "folder" containing the email. */
> > > +full_folder_name =3D g_strdup(path);
> > > +while (1)
> > > +{
> > > +folder_base_name =3D g_path_get_basename(full_folder_name);
> >
> > The trailing directory name is available already during the
> > traversal. So you don't need to search it back out again. See the patch
> > in the following message:
> >
> > id:87fx8bygi7.fsf at linux.vnet.ibm.com
> >
> > which simply passes the trailing directory name along, (but skipping a
> > name of "cur" or "new" while traversing).
> 
> 4. supporting hierarchical folders (perhaps this is a later improvement
> 
> that does not need to be added before the original patch is accepted?):
> > Beyond that, though, I imagine some people have hierarchical folders as
> > well, so it probably makes sense to store them as well.
> >
> > To do that, it's probably just a matter of calling gen_terms on the
> > complete filename. I haven't tested, but doing that should allow
> > Xapian's phrase searching to do the right thing for something like:
> >
> > filename:portion/of/the/path/name

I leave these two points for later since I do not have time for them now. If 
somebody want to do it, let me know.

Cheers
Michal


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

2010-01-28 Thread Ben Gamari
Excerpts from martin f krafft's message of Thu Jan 28 15:39:10 -0500 2010:
> also sprach Servilio Afre Puentes  [2010.01.29.0132 
> +1300]:
> > >> [tags]
> > >> inbox = +inbox,+unread
> > >> sent = +sent
> > >> drafts = +draft
> > >> archive = -inbox
> > >
> > > This proposal, on the other hand, is an interesting one, but when is
> > > it supposed to happen? It just feels wrong to make this happen as
> > > part of 'notmuch new'.
> > 
> > Why so?
> 
> I guess I just dislike having to run notmuch new regularly, rather
> than integrating the database more closely with the mail flow.
> 
Sounds like you need to add a line to crontab.

- Ben


[notmuch] [PATCH 2/2] Preserve folder information when indexing

2010-01-28 Thread micah anderson
On Thu, 28 Jan 2010 16:25:17 +0100, Michal Sojka  wrote:
> This patch was originally sent by Andreas Kl?ckner. This is a slightly
> reworked version (only coding style changes) which was manually rebased
> to the current HEAD.

Just a quick note about this patch: I received an offline email back


[notmuch] Small Fixes

2010-01-28 Thread Matt Fowles
All~

The attached patches fix a compiler warning in
notmuch_message_get_filename and add the generated test directories to
the .gitignore file.

Matt
-- next part --
A non-text attachment was scrubbed...
Name: ignore.patch
Type: application/octet-stream
Size: 327 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/585f1d03/attachment.obj>
-- next part --
A non-text attachment was scrubbed...
Name: warning.patch
Type: application/octet-stream
Size: 1964 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/585f1d03/attachment-0001.obj>


[notmuch] Internal error no thread ID

2010-01-28 Thread Olly Betts
On 2010-01-27, Matthias Teege wrote:
> 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?

You can get it from the database using Xapian's delve utility:

delve -d -r62004 /PATH/TO/XAPIAN-DATABASE

Cheers,
Olly



[notmuch] Git feature branch

2010-01-28 Thread martin f krafft
also sprach micah anderson  [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 (git.debian.org, gitorious,
> their own hosted git repositories, or even github) and then Carl
> can just add those as remotes as he sees fit.

I brought this up, so I should make the motivation explicit: I just
tried to relieve Carl from the burden of bottleneck. Since passing
out SSH accounts on his own machine does not really scale, I looked
elsewhere.

However, I agree that the easiest solution is just to add more
users. Potentially, Carl can make use of gitolite, I can investigate
that some time this week.

> 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 non-Debian native
> program (but using it for the Debian package of notmuch does make
> sense). I am not so familiar with Roundup, patch queue trackers or
> patchwork to have anything to say about those.

patchwork integrates with the mailing list and slurps patches and
related discussion and threads them into a webpage, where they can
be workflow-managed.

The Debian bug tracker has the benefit of being usable with e-mail
(and this is notmuch we're developing, don't forget). The others are
all exclusively web-based, with the exception of launchpad, AFAIK.

The idea of having a tracker is quite simply to make it easier for
Carl to stay on top, and for e.g. you and I to assist him by vetting
patches in our free minutes.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

there's an old proverb that says just about whatever you want it to.

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100128/a583bd71/attachment.pgp>


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

2010-01-28 Thread Servilio Afre Puentes
2010/1/28 martin f krafft :
> also sprach Jameson Rollins  [2010.01.26.1046 
> +1300]:
>> > For example, I might have:
>> >
>> > ~/.notmuch-config:
>> >
>> > ? ? [database]
>> > ? ? path=/home/pioto/mail
>> > ? ? ...
>> > ? ? [tags]
>> > ? ? pioto at pioto.org/INBOX.ListMail.notmuch = notmuch
>> >
>> > So, a 'tags' section, where each key is the folder name, relative to the
>> > db path, and the value is one or more tag names
>>
>> I think this idea is a really good one and I would like to pursue it as
>> a tangent thread here. ?I was going to propose something very similar to
>> this. ?I think it's a very flexible idea that would help in a lot of
>> ways.
>
> I think we need to carefully distinguish here. The above seems to
> suggest a mapping from folder to tag, but we don't actually need
> tags for folder locations because those can (and should) be implicitly
> determined from the database

I think that the usefulness of this functionality is that we can have
a mapping from physical organization of the mail to a tagging scheme
of our choosing, and we can be relieved from having to remember the
location of the mail (that can be different in different from
different mail clients).

But even right now I can't find a documented way of searching by
location, so AFAIK the implementation of this proposal would allow
something that is not possible at the moment.

>> [tags]
>> inbox = +inbox,+unread
>> sent = +sent
>> drafts = +draft
>> archive = -inbox
>
> This proposal, on the other hand, is an interesting one, but when is
> it supposed to happen? It just feels wrong to make this happen as
> part of 'notmuch new'.

Why so?

> What I would like to see is a notmuch-aware MDA, e.g. a programme
> which reads an incoming mail on stdin and can do all this kind of
> stuff, e.g. assign tags based on such rules (or take tags as
> arguments, so that I could trivially set tags from procmail too),
> write the message to the message store, and update the database.

Such an MDA wouldn't need to use "notmuch new", and thus won't be
affected by this

> This would allow us to get rid of 'notmuch new' altogether, at least
> conceptually. We'd still need it if mail is being delivered
> independently, e.g. with offlineimap.

Then we'd still need it, why not make it better?

Regards,

Servilio


[notmuch] Git feature branch

2010-01-28 Thread James Rowe
* martin f krafft (madduck at madduck.net) wrote:
> also sprach micah anderson  [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 non-Debian native
> > program (but using it for the Debian package of notmuch does make
> > sense). I am not so familiar with Roundup, patch queue trackers or
> > patchwork to have anything to say about those.
>
> patchwork integrates with the mailing list and slurps patches and
> related discussion and threads them into a webpage, where they can
> be workflow-managed.
>
> The Debian bug tracker has the benefit of being usable with e-mail
> (and this is notmuch we're developing, don't forget). The others are
> all exclusively web-based, with the exception of launchpad, AFAIK.

  As I use some of the other options...

  Roundup has command line and email interfaces.  The email interface is
quite similar to debian's.  I've never used a launchpad hosted project
so I can't compare it.

  Google's codereview tool has a nice interface for collecting and
commenting on patches, but I suspect that suggestion will also meet with
a degree of friction.  To me codereview feels like patchwork with
polish.

  Both gitorious and github have commenting functionality built in.
Commenting on commits in a fork is as easy as opening the commit in
a browser.  I use something along the lines of the following script to
open commits on github:

#! /bin/sh
BASE=$(git config remote.${2:-origin}.url | sed 
's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,')
COMMIT=$(git rev-parse ${1:-HEAD})
sensible-browser ${BASE}/${COMMIT}

  Using github or gitorious you can easily find and track forks from one
place as well, which makes discovering new work much easier.  Github
even provides a pretty single page interface to the work going on in
other forks, gitorious requires a little more leg work to do the same
but not much.

  For a couple of hosted projects we use at the office we email the
individual entries from http://github.com/$user/$project/comments.atom
to the mailing list so they're /forcibly/ seen by everybody :)

Thanks,

James

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


[notmuch] [patch] store folder information

2010-01-28 Thread micah anderson

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 that
have not seen a reply from you yet. I'm particularly eager to see this
get accepted upstream, and it sounds like the changes necessary to do so
are relatively minor.

I'm wondering what your plans are for addressing these issues? I've come
to depend on this functionality, and would love to see it incorporated
upstream! 

Specifically these were:

1. Unrelated whitespace:

On December 16th,2009 Ruben Pollan  wrote:

> [meskio at blackspot:src/notmuch.orig]$ git apply 
> ~/0001-Preseve-folder-information-when-indexing.patch
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: 
> trailing whitespace.
>status notmuch_database_add_message (notmuch, next,
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: 
> trailing whitespace.
>   folder_base_name,
> warning: 2 lines add whitespace errors.
>
> It's just whitespaces at the end of the lines.

2. An unrelated hunk creeping in:

On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner  wrote:
> >
> > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > s++;
> > if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > s +=3D 3;
> > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > +   s +=3D 3;
> > else
> > break;
> >  }
>=20
> This hunk looks unrelated to the rest. Could you submit that separately,
> please?


3. Redundant trailing directory name traversal:

> > +gchar *full_folder_name =3D NULL;
> > +gchar *folder_base_name =3D NULL;
> > +
> > +/* Find name of "folder" containing the email. */
> > +full_folder_name =3D g_strdup(path);
> > +while (1)
> > +{
> > +folder_base_name =3D g_path_get_basename(full_folder_name);
>
> The trailing directory name is available already during the
> traversal. So you don't need to search it back out again. See the patch
> in the following message:
>
>   id:87fx8bygi7.fsf at linux.vnet.ibm.com
>
> which simply passes the trailing directory name along, (but skipping a
> name of "cur" or "new" while traversing).

4. supporting hierarchical folders (perhaps this is a later improvement
that does not need to be added before the original patch is accepted?):

> Beyond that, though, I imagine some people have hierarchical folders as
> well, so it probably makes sense to store them as well.
>
> To do that, it's probably just a matter of calling gen_terms on the
> complete filename. I haven't tested, but doing that should allow
> Xapian's phrase searching to do the right thing for something like:
>
>   filename:portion/of/the/path/name

5. Probably the patch needs to be rebased off of master at this point.

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/20100128/7c173e7f/attachment.pgp>


[notmuch] Backport of Xapian term update optimisation

2010-01-28 Thread Olly Betts
I've backported the term update optimisation patches
 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).

So if you're so inclined, try it and report how you got on (on this list
is fine).

Cheers,
Olly



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

2010-01-28 Thread Servilio Afre Puentes
2010/1/28 martin f krafft madd...@madduck.net:
 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 key is the folder name, relative to the
  db path, and the value is one or more tag names

 I think this idea is a really good one and I would like to pursue it as
 a tangent thread here.  I was going to propose something very similar to
 this.  I think it's a very flexible idea that would help in a lot of
 ways.

 I think we need to carefully distinguish here. The above seems to
 suggest a mapping from folder to tag, but we don't actually need
 tags for folder locations because those can (and should) be implicitly
 determined from the database

I think that the usefulness of this functionality is that we can have
a mapping from physical organization of the mail to a tagging scheme
of our choosing, and we can be relieved from having to remember the
location of the mail (that can be different in different from
different mail clients).

But even right now I can't find a documented way of searching by
location, so AFAIK the implementation of this proposal would allow
something that is not possible at the moment.

 [tags]
 inbox = +inbox,+unread
 sent = +sent
 drafts = +draft
 archive = -inbox

 This proposal, on the other hand, is an interesting one, but when is
 it supposed to happen? It just feels wrong to make this happen as
 part of 'notmuch new'.

Why so?

 What I would like to see is a notmuch-aware MDA, e.g. a programme
 which reads an incoming mail on stdin and can do all this kind of
 stuff, e.g. assign tags based on such rules (or take tags as
 arguments, so that I could trivially set tags from procmail too),
 write the message to the message store, and update the database.

Such an MDA wouldn't need to use notmuch new, and thus won't be
affected by this

 This would allow us to get rid of 'notmuch new' altogether, at least
 conceptually. We'd still need it if mail is being delivered
 independently, e.g. with offlineimap.

Then we'd still need it, why not make it better?

Regards,

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


[notmuch] [PATCH 1/2] Skip German aw: prefix in subjects

2010-01-28 Thread Michal Sojka
This was originally present in Andreas Klöckner's patch.
---
 lib/index.cc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/index.cc b/lib/index.cc
index 7e2da08..eb97f91 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
s++;
if (strncasecmp (s, re:, 3) == 0)
s += 3;
+else if (strncasecmp (s, aw:, 3) == 0)
+   s += 3;
else
break;
 }
-- 
1.6.6

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


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

2010-01-28 Thread martin f krafft
also sprach Servilio Afre Puentes servi...@gmail.com [2010.01.29.0132 +1300]:
  [tags]
  inbox = +inbox,+unread
  sent = +sent
  drafts = +draft
  archive = -inbox
 
  This proposal, on the other hand, is an interesting one, but when is
  it supposed to happen? It just feels wrong to make this happen as
  part of 'notmuch new'.
 
 Why so?

I guess I just dislike having to run notmuch new regularly, rather
than integrating the database more closely with the mail flow.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
to get back my youth i would do anything in the world, except take
 exercise, get up early, or be respectable.
-- oscar wilde
 
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] tag dir proposal [was: Re: Git as notmuch object store]

2010-01-28 Thread Ben Gamari
Excerpts from martin f krafft's message of Thu Jan 28 15:39:10 -0500 2010:
 also sprach Servilio Afre Puentes servi...@gmail.com [2010.01.29.0132 
 +1300]:
   [tags]
   inbox = +inbox,+unread
   sent = +sent
   drafts = +draft
   archive = -inbox
  
   This proposal, on the other hand, is an interesting one, but when is
   it supposed to happen? It just feels wrong to make this happen as
   part of 'notmuch new'.
  
  Why so?
 
 I guess I just dislike having to run notmuch new regularly, rather
 than integrating the database more closely with the mail flow.
 
Sounds like you need to add a line to crontab.

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


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

2010-01-28 Thread Jed Brown
On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari bgam...@gmail.com wrote:
 Sounds like you need to add a line to crontab.

I haven't been following this thread closely so I hope this isn't too
out of context.  I agree that certain things like notmuch-new should go
in the crontab, but I think that notmuch-new should need to be run
exactly once to process a new batch of messages into the desired state.

Having notmuch-new apply one set of tags and then relying on another
process run afterwards to change the tags according to a filter is
undesirable in my opinion, both for the mild performance reason of
making two passes, but more importantly because of lock contention
between the two processes and the ease of viewing the database in the
inconsistent state.  As far as I understand the situation, my favorite
solution is to have notmuch-new run a hook on each message as it is
indexed.

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