Re: [notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > I'm not at all trying to be pushy; there's just some older stuff in the > queue that I would really like to see applied, such as folder-based > tagging Hi, as for the folder-based tagging patch sent by myself, it needs some improvement. I'm waiting for merge of testing ifrastructure in order to write tests for the patch. The testing infrastructure is GPLv2 and we would like to use it under GPLv3 and changing this takes some time. I guess, Carl waits for this as well. Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > Hey, Carl. I've noticed that you've been applying some patches that > were recently sent to the list, out of order from the chronological > queue of patches that were sent to the list. I'm a fan of the recently > applied patches, but I'm curious about what your plans are for the older > patches in the quene. Are you still planning on processing them? > Should the older patches be rebased against the current master and > resent? Just my snippet of info from IRC: bremner: OK. So my plan: 1) Commit stash stuff. 2) Make emacs directory. 3) Find and apply all obvious notmuch.el patches And bremner can help me stay focused. After that: 1) Modularize test suite 2) Add testing of emacs stuff Then: 1) Add folder: search 2) Don't index data redundantly And: 1) Add --format (JSON) 2) Add --output There. Now I've published a plan at least. luckily there are no public logs . hehe, wrong ;-) Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > Hey, Carl. I've noticed that you've been applying some patches that > were recently sent to the list, out of order from the chronological > queue of patches that were sent to the list. I'm a fan of the recently > applied patches, but I'm curious about what your plans are for the older > patches in the quene. Are you still planning on processing them? > Should the older patches be rebased against the current master and > resent? Thanks for asking, Jamie. I'm still planning on processing the entire queue, (and chronologically), but I'm definitely capable of being influenced to grab stuff from the "future" > I'm not at all trying to be pushy; there's just some older stuff in the > queue that I would really like to see applied, such as folder-based > tagging, json output, and some of the emacs UI improvements. You're not being pushy at all. Please feel free to let me know what you think is most important. I totally agree on the things mentioned above as being priority. I want folder-based tagging myself, and there are a *lot* of interesting things that are blocking on json output. Meanwhile, shortcomings in the emacs UI are causing me problems on a constant basis, (the latest thing driving me crazy is the regression that refreshing search results makes the current position in the search results get lost). For folder-based tagging, that will cause an increment in the database-format version, so I'd like to do a couple of other things at the same time. One is to enable indexing of additional headers, (spam flags, and mailing-list headers), and the other is to stop doing redundant indexing of data under multiple prefixes[*]. For the emacs UI improvements, I do plan on making an early sweep of the patch queue and applying them, (if only because I have some improvements I need to make myself, and I want to avoid doing anything that's already been done). Thanks for your input, and please feel free to let me know your thoughts at any time. -Carl [*] This idea came from an equivalent fix recently made to sup. We are currently indexing the subject, for example, with a "subject:" prefix and also with no prefix, (to match search terms with no prefix). The fix is to just index it with the "subject:" prefix, but then at search time to take any un-prefixed terms and match them against a whole list of prefixes, (subject:, from:, to:, etc.). This should be a nice savings on our database size with no appreciable performance cost. pgppbNp9wdS4R.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
From 8693995fde71e8b028318e1e83bdbb6ae759335a Mon Sep 17 00:00:00 2001 From: Carl Worth Date: Sat, 20 Feb 2010 11:41:24 -0800 Subject: [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+. This file has had no explicit license information noted in it, but has clearly been created and modified according to the terms of GPLv2 as with the rest of the git code base. The purpose of relicensing is to allow other GPLv3+ projects (in particular, the notmuch project: http://notmuchmail.org) to use this same test-suite structure and to contribute changes back as well. The relicensing was agreed to by Junio C Hamano here: http://thread.gmane.org/gmane.mail.notmuch.general/1389/focus=140156 and in follow-up messages by Sverre Rabbelier, Johannes Schindelin, Pierre Habouzit, and Johannes Sixt. Signed-off-by: Carl Worth Acked-by: Johannes Schindelin --- > Message-ID alone is not a good way to help people locate the request. > Please at least mention what mailing list the message was sent to; better > yet, do so like this: Done as requested. But while we're on the subject, let me at least make a case for communication by way of Message-ID. The URL above is good for as long as gmane continues to live, but that may not be as long as the git project (and its mailing-list archives) are interesting. Meanwhile, a message ID lives forever and can be used in multiple contexts. For example, gmane does already support message-ID-based URLs: http://mid.gmane.org/7vaav3bnr5@alter.siamese.dyndns.org That interface happens to only display the single message, (requiring clicking on the subject to see the thread), but one can imagine gmane getting a similar interface to display the thread directly from the message ID. Meanwhile, people using systems like notmuch can also use the message ID directly to view the thread, with something like: notmuch show id:7vaav3bnr5@alter.siamese.dyndns.org So I'm very much in favor of using message IDs more regularly, (and just expecting that users and their tools will be more accepting of them). But for now, you've hopefully got your commit message the way you want it. :-) t/test-lib.sh | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index afd3053..004470f 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -2,6 +2,18 @@ # # Copyright (c) 2005 Junio C Hamano # +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/ . # if --tee was passed, write the output not only to the terminal, but # additionally to the file test-results/$BASENAME.out, too. -- 1.6.5.7 pgpaqtchFdAuV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
Hi, On Sun, Feb 21, 2010 at 3:55 AM, Carl Worth wrote: > The request for relicensing was presented to the git community in: > > Message-ID: <871vgmki4f@steelpick.localdomain> > > and explicitly agreed to by Junio C Hamano, Sverre Rabbelier, Johannes > Schindelin, Pierre Habouzit, and Johannes Sixt. (of all projects, Mercurial!) take a look at Mercurial's attempt at relicensing last year (http://mercurial.selenic.com/wiki/Relicensing): they contacted all 300+ contributors as part of the process. Of course, we aren't talking about relicensing the whole codebase. However, I don't think any of the contributors agreed to assign their work to the 5 people mentioned above (eg. under a contributor licence agreement), so just getting the approval of them is not enough; you need to get the approval of *all* contributors to test-lib.sh. Here's what I get with 'git shortlog t/test-lib.sh | grep "^[A-Z]"' Alex Riesen (5): Brandon Casey (2): Bryan Donlan (3): Carl Worth (1): Christian Couder (1): Clemens Buchacher (3): David Reiss (1): Emil Sit (1): Eric Wong (3): Fredrik Kuivinen (1): Gerrit Pape (1): Jakub Narebski (1): Jeff King (7): Johan Herland (1): Johannes Schindelin (14): Johannes Sixt (12): Jonathan Nieder (1): Josh Triplett (1): Junio C Hamano (57): Lea Wiemann (5): Markus Heidelberg (1): Martin Waitz (1): Matthew Ogilvie (1): Matthias Lederhofer (1): Michael J Gruber (4): Michele Ballabio (2): Miklos Vajna (1): Nicolas Pitre (1): Pavel Roskin (3): Petr Baudis (3): Pierre Habouzit (2): Robin Rosenberg (1): Shawn O. Pearce (4): Stephan Beyer (1): Stephen Boyd (1): Sverre Rabbelier (2): PS: This message should not be construed as legal advice. -- Cheers, Ray Chuan ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Added mail directory filename pattern support.
Typically, the filenames in a mail directory that actually
contain mail obey some specific format. For example, in my
MH email directory, all mail filenames consist only of
digits.
This patch adds support for a config file variable
"filename_pattern" which maybe set to a regex used to filter
only valid mail filenames when scanning. Effective use of
filename_pattern cuts down on the noise from notmuch, and
may speed it up in some cases.
Signed-off-by: Bart Massey
---
notmuch-client.h |7 +++
notmuch-config.c | 47 +--
notmuch-new.c| 35 +++
3 files changed, 83 insertions(+), 6 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..191988c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -146,6 +146,13 @@ notmuch_config_set_database_path (notmuch_config_t *config,
const char *database_path);
const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config);
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex);
+
+const char *
notmuch_config_get_user_name (notmuch_config_t *config);
void
diff --git a/notmuch-config.c b/notmuch-config.c
index 95430db..4189f03 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -31,11 +31,22 @@ static const char toplevel_config_comment[] =
static const char database_config_comment[] =
" Database configuration\n"
"\n"
-" The only value supported here is 'path' which should be the top-level\n"
+" The value 'path' should be the top-level\n"
" directory where your mail currently exists and to where mail will be\n"
" delivered in the future. Files should be individual email messages.\n"
" Notmuch will store its database within a sub-directory of the path\n"
-" configured here named \".notmuch\".\n";
+" configured here named \".notmuch\".\n"
+"\n"
+" The optional value 'filename_pattern' should be\n"
+" a POSIX regular expression matching only those\n"
+" filenames that will be checked for email\n"
+" messages. The match is against the last\n"
+" component of the pathname only. Anchors may be\n"
+" used, and probably should be. Typically, this\n"
+" is used to match only files whose name is a\n"
+" number ala MH, or to match only files in\n"
+" standard maildir format. The default pattern\n"
+" matches anything.\n";
static const char user_config_comment[] =
" User configuration\n"
@@ -58,6 +69,7 @@ struct _notmuch_config {
GKeyFile *key_file;
char *database_path;
+char *filename_regex;
char *user_name;
char *user_primary_email;
char **user_other_email;
@@ -151,6 +163,8 @@ get_username_from_passwd_file (void *ctx)
*
* database_path: $HOME/mail
*
+ * filename_pattern: .*
+ *
* user_name: From /etc/passwd
*
* user_primary_mail: $EMAIL variable if set, otherwise
@@ -195,6 +209,7 @@ notmuch_config_open (void *ctx,
config->key_file = g_key_file_new ();
config->database_path = NULL;
+config->filename_regex = NULL;
config->user_name = NULL;
config->user_primary_email = NULL;
config->user_other_email = NULL;
@@ -354,6 +369,34 @@ notmuch_config_set_database_path (notmuch_config_t *config,
}
const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config)
+{
+char *regex;
+
+if (config->filename_regex == NULL) {
+ regex = g_key_file_get_string (config->key_file,
+ "database", "filename_pattern", NULL);
+ if (regex) {
+ config->filename_regex = talloc_strdup (config, regex);
+ free (regex);
+ }
+}
+
+return config->filename_regex;
+}
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex)
+{
+g_key_file_set_string (config->key_file,
+ "database", "filename_pattern", filename_regex);
+
+talloc_free (config->filename_regex);
+config->filename_regex = NULL;
+}
+
+const char *
notmuch_config_get_user_name (notmuch_config_t *config)
{
char *name;
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..531f9a3 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,8 @@
#include "notmuch-client.h"
#include
+#include
+#include
typedef struct _filename_node {
char *filename;
@@ -207,6 +209,7 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
static notmuch_status_t
add_files_recursive (notmuch_database_t *notmuch,
const char *path,
+const regex_t *maybe_regex,
add_files_state_t *state)
{
DIR *dir = NULL;
@@ -302,7 +305,7 @@ add_files_recursive (notmuch_database_t *notmuch,
}
next = tallo
Re: [notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use
The above patch and script don't deal with attachments or inline html, both of which require (for now) that the mail file be present locally. That may not be necessary with planned changed to notmuch in the future. For the time being, though, you can get attachments and html to work with over TRAMP, by adding the following to your .emacs file, which I'm sharing based on the encouragement of some folks on IRC: (setq notmuch-command "/script/in/the/above/message") (setq notmuch-remote-host "y...@your.remote.host") ;; tell notmuch-show-get-filename to use TRAMP to open the file (defadvice notmuch-show-get-filename (around notmuch-show-get-remote-filename activate) (setq ad-return-value (concat "/ssh:" notmuch-remote-host ":" ad-do-it))) There's an annoying bit of redundancy in the fact that you have to define your remote server both in the elisp and in the shell-script. You could possibly extract it from the script if you wanted to, but that seems like it might be prone to error. Like the script, this requires password-less login to your ssh server. You can also speed this up by using an already open connection, using the ControlMaster feature in openssh. All best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
Carl Worth writes: > From 8693995fde71e8b028318e1e83bdbb6ae759335a Mon Sep 17 00:00:00 2001 > From: Carl Worth > Date: Sat, 20 Feb 2010 11:41:24 -0800 > Subject: [PATCH] test-lib.sh: Add explicit license detail, with change from > GPLv2 to GPLv2+. Please drop the above the next time. > The relicensing was agreed to by Junio C Hamano here: > > http://thread.gmane.org/gmane.mail.notmuch.general/1389/focus=140156 > > and in follow-up messages by Sverre Rabbelier, Johannes Schindelin, > Pierre Habouzit, and Johannes Sixt. FWIW, I only said "_at least_ you need consent from them", and it was not meant to be an exhaustive list. "blame -C -C -C" may tell you more. You are the party that wants this relicensing, not me. Please do not burden me with excessive legwork for you, but help me a bit more proactively to make this happen. > Meanwhile, a message ID lives forever and can be used in multiple > contexts. Oh, I never said "do not use message ID". I said "message ID alone is not good enough for most people". Users of gmane and notmuch who know the tool they use would benefit from having message ID, _too_, but even if you were a user of notmuch, unless you have subscribed to the list and have your own archive, you wouldn't be able to say "show id:frotz". ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
Hi, On Tue, Feb 23, 2010 at 11:42 AM, Junio C Hamano wrote: > FWIW, I only said "_at least_ you need consent from them", and it was not > meant to be an exhaustive list. "blame -C -C -C" may tell you more. Without substantial analysis, "blame" alone is not sufficient - it does not show which work was original, or derivative. -- Cheers, Ray Chuan ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Added mail directory filename pattern support.
On Mon, Feb 22, 2010 at 12:07:31PM -0800, Bart Massey wrote: > Typically, the filenames in a mail directory that actually > contain mail obey some specific format. For example, in my > MH email directory, all mail filenames consist only of > digits. > > This patch adds support for a config file variable > "filename_pattern" which maybe set to a regex used to filter > only valid mail filenames when scanning. Effective use of > filename_pattern cuts down on the noise from notmuch, and > may speed it up in some cases. What about the other way around? e.g. if anybody has ever pointed Evolution at a Maildir, you get a bunch of Maildir-name.ev-summary and .ev-summary-meta and .ibex.index and whatever. A default list of ignored patterns would be pretty easy to come up with. -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > I'm not at all trying to be pushy; there's just some older stuff in the > queue that I would really like to see applied, such as folder-based > tagging Hi, as for the folder-based tagging patch sent by myself, it needs some improvement. I'm waiting for merge of testing ifrastructure in order to write tests for the patch. The testing infrastructure is GPLv2 and we would like to use it under GPLv3 and changing this takes some time. I guess, Carl waits for this as well. Michal
[notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > Hey, Carl. I've noticed that you've been applying some patches that > were recently sent to the list, out of order from the chronological > queue of patches that were sent to the list. I'm a fan of the recently > applied patches, but I'm curious about what your plans are for the older > patches in the quene. Are you still planning on processing them? > Should the older patches be rebased against the current master and > resent? Just my snippet of info from IRC: bremner: OK. So my plan: 1) Commit stash stuff. 2) Make emacs directory. 3) Find and apply all obvious notmuch.el patches And bremner can help me stay focused. After that: 1) Modularize test suite 2) Add testing of emacs stuff Then: 1) Add folder: search 2) Don't index data redundantly And: 1) Add --format (JSON) 2) Add --output There. Now I've published a plan at least. luckily there are no public logs . hehe, wrong ;-) Sebastian
[notmuch] patch queue
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins wrote: > Hey, Carl. I've noticed that you've been applying some patches that > were recently sent to the list, out of order from the chronological > queue of patches that were sent to the list. I'm a fan of the recently > applied patches, but I'm curious about what your plans are for the older > patches in the quene. Are you still planning on processing them? > Should the older patches be rebased against the current master and > resent? Thanks for asking, Jamie. I'm still planning on processing the entire queue, (and chronologically), but I'm definitely capable of being influenced to grab stuff from the "future" > I'm not at all trying to be pushy; there's just some older stuff in the > queue that I would really like to see applied, such as folder-based > tagging, json output, and some of the emacs UI improvements. You're not being pushy at all. Please feel free to let me know what you think is most important. I totally agree on the things mentioned above as being priority. I want folder-based tagging myself, and there are a *lot* of interesting things that are blocking on json output. Meanwhile, shortcomings in the emacs UI are causing me problems on a constant basis, (the latest thing driving me crazy is the regression that refreshing search results makes the current position in the search results get lost). For folder-based tagging, that will cause an increment in the database-format version, so I'd like to do a couple of other things at the same time. One is to enable indexing of additional headers, (spam flags, and mailing-list headers), and the other is to stop doing redundant indexing of data under multiple prefixes[*]. For the emacs UI improvements, I do plan on making an early sweep of the patch queue and applying them, (if only because I have some improvements I need to make myself, and I want to avoid doing anything that's already been done). Thanks for your input, and please feel free to let me know your thoughts at any time. -Carl [*] This idea came from an equivalent fix recently made to sup. We are currently indexing the subject, for example, with a "subject:" prefix and also with no prefix, (to match search terms with no prefix). The fix is to just index it with the "subject:" prefix, but then at search time to take any un-prefixed terms and match them against a whole list of prefixes, (subject:, from:, to:, etc.). This should be a nice savings on our database size with no appreciable performance cost. -- 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/20100222/63eb9098/attachment.pgp>
[notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
[notmuch] [PATCH] Added mail directory filename pattern support.
Typically, the filenames in a mail directory that actually
contain mail obey some specific format. For example, in my
MH email directory, all mail filenames consist only of
digits.
This patch adds support for a config file variable
"filename_pattern" which maybe set to a regex used to filter
only valid mail filenames when scanning. Effective use of
filename_pattern cuts down on the noise from notmuch, and
may speed it up in some cases.
Signed-off-by: Bart Massey
---
notmuch-client.h |7 +++
notmuch-config.c | 47 +--
notmuch-new.c| 35 +++
3 files changed, 83 insertions(+), 6 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..191988c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -146,6 +146,13 @@ notmuch_config_set_database_path (notmuch_config_t *config,
const char *database_path);
const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config);
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex);
+
+const char *
notmuch_config_get_user_name (notmuch_config_t *config);
void
diff --git a/notmuch-config.c b/notmuch-config.c
index 95430db..4189f03 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -31,11 +31,22 @@ static const char toplevel_config_comment[] =
static const char database_config_comment[] =
" Database configuration\n"
"\n"
-" The only value supported here is 'path' which should be the top-level\n"
+" The value 'path' should be the top-level\n"
" directory where your mail currently exists and to where mail will be\n"
" delivered in the future. Files should be individual email messages.\n"
" Notmuch will store its database within a sub-directory of the path\n"
-" configured here named \".notmuch\".\n";
+" configured here named \".notmuch\".\n"
+"\n"
+" The optional value 'filename_pattern' should be\n"
+" a POSIX regular expression matching only those\n"
+" filenames that will be checked for email\n"
+" messages. The match is against the last\n"
+" component of the pathname only. Anchors may be\n"
+" used, and probably should be. Typically, this\n"
+" is used to match only files whose name is a\n"
+" number ala MH, or to match only files in\n"
+" standard maildir format. The default pattern\n"
+" matches anything.\n";
static const char user_config_comment[] =
" User configuration\n"
@@ -58,6 +69,7 @@ struct _notmuch_config {
GKeyFile *key_file;
char *database_path;
+char *filename_regex;
char *user_name;
char *user_primary_email;
char **user_other_email;
@@ -151,6 +163,8 @@ get_username_from_passwd_file (void *ctx)
*
* database_path: $HOME/mail
*
+ * filename_pattern: .*
+ *
* user_name: From /etc/passwd
*
* user_primary_mail: $EMAIL variable if set, otherwise
@@ -195,6 +209,7 @@ notmuch_config_open (void *ctx,
config->key_file = g_key_file_new ();
config->database_path = NULL;
+config->filename_regex = NULL;
config->user_name = NULL;
config->user_primary_email = NULL;
config->user_other_email = NULL;
@@ -354,6 +369,34 @@ notmuch_config_set_database_path (notmuch_config_t *config,
}
const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config)
+{
+char *regex;
+
+if (config->filename_regex == NULL) {
+ regex = g_key_file_get_string (config->key_file,
+ "database", "filename_pattern", NULL);
+ if (regex) {
+ config->filename_regex = talloc_strdup (config, regex);
+ free (regex);
+ }
+}
+
+return config->filename_regex;
+}
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex)
+{
+g_key_file_set_string (config->key_file,
+ "database", "filename_pattern", filename_regex);
+
+talloc_free (config->filename_regex);
+config->filename_regex = NULL;
+}
+
+const char *
notmuch_config_get_user_name (notmuch_config_t *config)
{
char *name;
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..531f9a3 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,8 @@
#include "notmuch-client.h"
#include
+#include
+#include
typedef struct _filename_node {
char *filename;
@@ -207,6 +209,7 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
static notmuch_status_t
add_files_recursive (notmuch_database_t *notmuch,
const char *path,
+const regex_t *maybe_regex,
add_files_state_t *state)
{
DIR *dir = NULL;
@@ -302,7 +305,7 @@ add_files_recursive (notmuch_database_t *notmuch,
}
next = talloc_asprint
[notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use
The above patch and script don't deal with attachments or inline html, both of which require (for now) that the mail file be present locally. That may not be necessary with planned changed to notmuch in the future. For the time being, though, you can get attachments and html to work with over TRAMP, by adding the following to your .emacs file, which I'm sharing based on the encouragement of some folks on IRC: (setq notmuch-command "/script/in/the/above/message") (setq notmuch-remote-host "you at your.remote.host") ;; tell notmuch-show-get-filename to use TRAMP to open the file (defadvice notmuch-show-get-filename (around notmuch-show-get-remote-filename activate) (setq ad-return-value (concat "/ssh:" notmuch-remote-host ":" ad-do-it))) There's an annoying bit of redundancy in the fact that you have to define your remote server both in the elisp and in the shell-script. You could possibly extract it from the script if you wanted to, but that seems like it might be prone to error. Like the script, this requires password-less login to your ssh server. You can also speed this up by using an already open connection, using the ControlMaster feature in openssh. All best, Jesse
[notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.
Carl Worth writes: > From 8693995fde71e8b028318e1e83bdbb6ae759335a Mon Sep 17 00:00:00 2001 > From: Carl Worth > Date: Sat, 20 Feb 2010 11:41:24 -0800 > Subject: [PATCH] test-lib.sh: Add explicit license detail, with change from > GPLv2 to GPLv2+. Please drop the above the next time. > The relicensing was agreed to by Junio C Hamano here: > > http://thread.gmane.org/gmane.mail.notmuch.general/1389/focus=140156 > > and in follow-up messages by Sverre Rabbelier, Johannes Schindelin, > Pierre Habouzit, and Johannes Sixt. FWIW, I only said "_at least_ you need consent from them", and it was not meant to be an exhaustive list. "blame -C -C -C" may tell you more. You are the party that wants this relicensing, not me. Please do not burden me with excessive legwork for you, but help me a bit more proactively to make this happen. > Meanwhile, a message ID lives forever and can be used in multiple > contexts. Oh, I never said "do not use message ID". I said "message ID alone is not good enough for most people". Users of gmane and notmuch who know the tool they use would benefit from having message ID, _too_, but even if you were a user of notmuch, unless you have subscribed to the list and have your own archive, you wouldn't be able to say "show id:frotz".
