Re: [notmuch] [RFC/PATCH] Add search-files command
Hi Ali,
On Wed, 13 Jan 2010 12:24:22 +0200, Ali Polatel a...@exherbo.org wrote:
This command can be used to integrate notmuch with other MUAs as a
searching client. The idea is simple, a simple script could get
search-terms as argument and create a virtual maildir which has
symbolic links to files output by search-files command. This is similar
to nmzmail.
---
Makefile.local |1 +
notmuch-client.h |3 +
notmuch-search-files.c | 107
notmuch.c | 13 ++
4 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 notmuch-search-files.c
diff --git a/Makefile.local b/Makefile.local
index 933ff4c..78bc25d 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -12,6 +12,7 @@ notmuch_client_srcs = \
notmuch-reply.c \
notmuch-restore.c \
notmuch-search.c\
+ notmuch-search-files.c \
notmuch-search-tags.c \
notmuch-setup.c \
notmuch-show.c \
diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..d505d30 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -96,6 +96,9 @@ int
notmuch_search_command (void *ctx, int argc, char *argv[]);
int
+notmuch_search_files_command (void *ctx, int argc, char *argv[]);
+
+int
notmuch_setup_command (void *ctx, int argc, char *argv[]);
int
diff --git a/notmuch-search-files.c b/notmuch-search-files.c
new file mode 100644
index 000..b48783a
--- /dev/null
+++ b/notmuch-search-files.c
@@ -0,0 +1,107 @@
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright © 2009 Carl Worth
I almost certainly should not be speaking in the name of Carl, but a
few weeks ago he replied with the following words to a message which
somehow raised the discussion of copyright holding in notmuch source
code:
Please feel free to retain your own copyright. I certainly don't
deserve anything being assigned to me.
The message-id of his reply is: 873a34tf8b@yoom.home.cworth.org,
just in the case you want to check the context in which it occurred.
+ *
+ * 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 3 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/ .
+ *
+ * Author: Ali Polatel a...@exherbo.org
+ */
+
+#include notmuch-client.h
+
+static void
+do_search_files (notmuch_query_t *query)
+{
+notmuch_message_t *message;
+notmuch_messages_t *messages;
+
+for (messages = notmuch_query_search_messages (query);
+ notmuch_messages_has_more (messages);
+ notmuch_messages_advance (messages))
+{
+ message = notmuch_messages_get (messages);
+ printf (%s\n, notmuch_message_get_filename (message));
+ notmuch_message_destroy(message);
+}
+}
+
+int
+notmuch_search_files_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *notmuch;
+notmuch_query_t *query;
+char *query_str;
+char *opt;
+notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
+int i;
+
+for (i = 0; i argc argv[i][0] == '-'; i++) {
+ if (strcmp (argv[i], --) == 0) {
+ i++;
+ break;
+ }
+if (STRNCMP_LITERAL (argv[i], --sort=) == 0) {
+ opt = argv[i] + sizeof (--sort=) - 1;
+ if (strcmp (opt, oldest-first) == 0) {
+ sort = NOTMUCH_SORT_OLDEST_FIRST;
+ } else if (strcmp (opt, newest-first) == 0) {
+ sort = NOTMUCH_SORT_NEWEST_FIRST;
+ } else {
+ fprintf (stderr, Invalid value for --sort: %s\n, opt);
+ return 1;
+ }
+ } else {
+ fprintf (stderr, Unrecognized option: %s\n, argv[i]);
+ return 1;
+ }
+}
+
+argc -= i;
+argv += i;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+ return 1;
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path
(config),
+ NOTMUCH_DATABASE_MODE_READ_ONLY);
+if (notmuch == NULL)
+ return 1;
+
+query_str = query_string_from_args (ctx, argc, argv);
+if (query_str == NULL) {
+ fprintf (stderr, Out of memory.\n);
+ return 1;
+}
+if (*query_str == '\0') {
+ fprintf (stderr, Error: notmuch search-files requires at least one
search
Re: [notmuch] [RFC/PATCH] Add search-files command
Fernando Carrijo yazmış:
Hi Ali,
Hey Fernando,
On Wed, 13 Jan 2010 12:24:22 +0200, Ali Polatel a...@exherbo.org wrote:
snip
diff --git a/notmuch-search-files.c b/notmuch-search-files.c
new file mode 100644
index 000..b48783a
--- /dev/null
+++ b/notmuch-search-files.c
@@ -0,0 +1,107 @@
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright © 2009 Carl Worth
I almost certainly should not be speaking in the name of Carl, but a
few weeks ago he replied with the following words to a message which
somehow raised the discussion of copyright holding in notmuch source
code:
Please feel free to retain your own copyright. I certainly don't
deserve anything being assigned to me.
The message-id of his reply is: 873a34tf8b@yoom.home.cworth.org,
just in the case you want to check the context in which it occurred.
Thanks, I don't really care about who owns the copyright as long as it's
open source but I'll change it if that's what Carl wishes.
snip
+if (*query_str == '\0') {
+ fprintf (stderr, Error: notmuch search-files requires at least one
search term.\n);
Could we break this line so that it did not go beyond the column limit
set by the coding conventions? Maybe we should go one step further and
import the file CODING_STYLE from cairo into notmuch's repository.
Sure, I didn't know much about the coding style and as you said there's
no document about it in notmuch's repository.
+ return 1;
+}
+
+query = notmuch_query_create (notmuch, query_str);
+if (query == NULL) {
+ fprintf (stderr, Out of memory\n);
+ return 1;
+}
+
+notmuch_query_set_sort (query, sort);
+
+do_search_files (query);
+
+notmuch_query_destroy (query);
+notmuch_database_close (notmuch);
It is not something of major importance, but I realized that the
function notmuch_config_close is only being called when notmuch is
executed with no arguments. As we know, the kernel shall close all
open file descriptors upon program termination, but wouldn't it be
better if we did it explicitly? Or did I overlook something?
Nope, it's good coding practise to free all resources before exit, I
didn't do it for config because neither the search command does it.
I'll send an updated patch soonish and I'll also send a separate patch
for notmuch-search.c as well.
Kind regards,
Fernando Carrijo.
--
Regards,
Ali Polatel
pgpnA3Kk4RtUO.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Idea for storing tags
On Wed, 13 Jan 2010 00:39:14 -0500, Scott Morrison sm...@indev.ca wrote: Maybe a better approach would be content addressing (see below). Content hashing -- good Idea ( not something that has hit me before) -- better than Message-Id as I believe there are still some MUA /MTAs that allow messages without message ids. The only potential issue with this is that it is critical then to preserve the message source against encoding changes though that shouldn't be too hard to avoid. Another problem with content-based naming for messages is that most of the messages in my mail store that I consider duplicates don't actually have identical content. (One is sent directly to me via CC and the other is sent by the mailing-list software *after* appending a footer to the message.) That said, notmuch already does use a sha-1 sum as the message identifier for any message that does not have a valid Message-ID header. So there's definitely a place for this. -Carl pgpc0PE5MY7sx.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [RFC/PATCH v2] Add search-files command
Jameson Rollins yazmış: On Wed, Jan 13, 2010 at 03:17:41PM +0200, Ali Polatel wrote: This command can be used to integrate notmuch with other MUAs as a searching client. The idea is simple, a simple script could get search-terms as argument and create a virtual maildir which has symbolic links to files output by search-files command. This is similar to nmzmail. Hi, Ali. I was also recently asking about a way to output just the file names of message resulting from searches. This is an important feature for handling deleting and moving in mail clients as well. I believe that Carl said this would be easier once he applied the JSON output patches that are in the queue right now. Hopefully we'll see those soon. Personally I think the right way to implement this from a UI perspective would be to just have an output filter for the 'search' subcommand, something like: notmuch search --output=filename search-term... If output formatting was well enough supported one could even imagine getting rid of the 'show' subcommand in favor of just the 'search' subcommand with output formatting options. That's even better! I think I'll be using my patch until these patches are merged :) jamie. -- Regards, Ali Polatel pgpnuTnG4qvFj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Potential problem using Git for mail (was: Idea for storing tags)
also sprach Jameson Rollins [2010.01.13.0838 +1300]: > What about if just the tag information is stored in the > repository, and not the mail itself? In that case only the user > would be pushing into the repo and you wouldn't have to worry > about the DoS scenario. I certainly would like the ability to have messages automatically-tagged on delivery, by procmail. -- martin | http://madduck.net/ | http://two.sentenc.es/ may the bluebird of happiness twiddle your bits. 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/20100113/4eed8a9b/attachment.pgp>
[notmuch] Idea for storing tags
Desc: Digital signature (see http://martin-krafft.net/gpg/) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100113/5762c94f/attachment.pgp>
[notmuch] Idea for storing tags
On 2010-01-12, at 8:24 PM, martin f krafft wrote: > also sprach Scott Morrison [2010.01.12.1711 +1300]: >> 1. synchronization of tag data with emails -- if they are in >> a subfolder then it presents the issue of maintaining this >> subfolder when managing emails (moving, deleting, duplicating etc) >> and any .tag folder unaware clients are likely cause an breakage >> in tagdata/message association. One way of doing this is to have >> a global .tag folder. > > A global .tag folder indexed by e.g. message ID, as you state later, > would probably allow for this. Or a file-per-tag design. We'd have > to think carefully about pros and cons for each. > > When thinking about this, I always have to remind myself that we are > targetting this at a design that has indexed search. If that weren't > the case, searches would be incredibly expensive. > > Maybe a better approach would be content addressing (see below). Content hashing -- good Idea (& not something that has hit me before) -- better than Message-Id as I believe there are still some MUA /MTAs that allow messages without message ids. The only potential issue with this is that it is critical then to preserve the message source against encoding changes though that shouldn't be too hard to avoid. > >> 2. what happens if that message is archived or moved to an >> exclusively local cache -- eg. Mail.app on OS X can easily move >> IMAP messages to a folder resident on the computers computers? > > Well, if the target can store tags, then ideally the MUA should know > how to transfer them along. > > Maybe the right thing to do would be to use extended attributes > (which are stored in the inode!), even if they may not be > universally supported yet. If our solution scales, then this might > lead to a significant increase in xattr adoption. The problem with anything that is not universally supported is that for a package that is to appeal to a wide userbase, most don't know and don't care about the particulars of this IMAP server vs that IMAP server. all they know it that for some reason it doesn't work with account X -- which leads to support head aches. > >> 3. what happens with duplicates of emails -- I would assume that >> the message id would be the key to match the tag data to the >> message. In this system a duplicate of a message could not have >> a different set of tags from the original (not that this would >> necessarily be desirable.) > > Duplicates need folders, and tags and folders are somewhat at odds > with each other. I mean, you can represent a folder hierarchy with > tags (and more), and if you have tags and folders, you are > potentially introducing a level of confusion/ambiguity that we don't > want in the first place. Maybe the ideal solution doesn't need > folders anymore (and IMAP-compatible (Maildir) subfolders have > always been a hack anyway). > > There are also two types of duplicates: copies and links. The former > can diverge, the latter can't. I don't really see a reason for > either. It's not like you need to copy a mail before you edit it, > and I don't see a real reason for linking, assuming that the primary > means of browsing will be tag-searches anyway. > > Duplicates always make me think of content addressing, like Git's > object cache. We could store the content hash of a message in its > filename, and also use the hash to index into the tag database. > I think that would be much cleaner than message IDs, and would make > handling true duplicates (links) much easier, while copies (diverged > ex-duplicates) would also be taken care of automatically. I agree that conceptually duplicates should be buried but end users do have "peculiar" organization systems. > > -snip- >> The performance issue is very real -- because it means that >> somehow messages have to rewritten to the IMAP server -- IMAP >> doesn't have a mechanism AFAIK for updates. > > Not even UIDPLUS? > http://wiki.dovecot.org/FeatUIDPLUS
[notmuch] Idea for storing tags
also sprach Scott Morrison [2010.01.13.1752 +1300]: > The problem with anything that is not universally supported is > that for a package that is to appeal to a wide userbase, most > don't know and don't care about the particulars of this IMAP > server vs that IMAP server. all they know it that for some reason > it doesn't work with account X -- which leads to support head > aches. [...] > Call it Googles problem as you like -- but when I have a product > that doesn't work with GMAIL IMAP there are a lot of potential > users that don't care about server peculiarities and rather just > have it work. Well, the way I see it: you cannot change all IMAP servers at once, and you certainly cannot change Google. If it's possible to implement tagging for email (dare say semantic e-mail) with standard means (where standard means sub-standard, as exemplified by your previous GMail IMAP example), then that's the best way, but if that can't happen then we ought to try a better way. Should we find a solution then, by the rate of standardisation on the 'Net, maybe my grandchildren will finally be able to do proper e-mail. ;) > I agree that conceptually duplicates should be buried but end > users do have "peculiar" organization systems. I think tags should help abstract e-mail away from underlying storage and I'd love that to be a goal. > From my reading, uidplus doesn't allow a delta modification of > a message on a server -- just to write a portion of a message back > -- you still have to write the whole thing back and that can mean > real bandwidth issues for some messages. Absolutely. It would indeed be better if you could just send changes. I just sent a blank mail to imap-protocol-subscribe at mailman.u.washington.edu and have started browsing the archives. So far, there's not really anything relevant. Anyway, looking back at the RFC on keywords, it's not exactly encouraging: A keyword is defined by the server implementation. Keywords do not begin with "\". Servers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information). Anyway, I'll try to untangle the various issues re:IMAP we've been seeing, write mails for each, and hopefully get to the point where I can enquire about IMAPv5. ;) -- martin | http://madduck.net/ | http://two.sentenc.es/ the unix philosophy basically involves giving you enough rope to hang yourself. and then some more, just to be sure. 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/20100113/b94f2b12/attachment.pgp>
[notmuch] Bug with commit 2e96464f9705be4ec772280cad71a6c9d5831e6f
Ali Polatel yazm??: > racin at free.fr yazm??: > > Hello, > > > > I just updated notmuch and now notmuch new cannot update my mail anymore... > > It tells me that there are > > 700 files found, but tells that there's no new mail. > > > > I did a git bisect, which tells me the first bad commit is commit > > 2e96464f9705be4ec772280cad71a6c9d5831e6f. > > > > I did not try to use the new xapian database or to update xapian; maybe > > this is the problem. > > > > I tested with several tools to get mail in the maildir format, including > > mb2md and getmail, and I always get the problem. > Same problem here, I tried upgrading xapian to xapian-core-1.1.3_svn13824, > the problem persists. > Here's what happens here: > 3074 alip at harikalardiyari> rm -fr .maildir/.notmuch > 3075 alip at harikalardiyari> notmuch new > Found 210302 total files (that's not much mail). > No new mail. > 3076 alip at harikalardiyari> notmuch search from:alip at exherbo.org > 3077 alip at harikalardiyari> > After doing git bisect which gave random results and testing notmuch using cworth's notmuch-test script on another file system I figured out my problem was due to file system corruption. Sorry for the noise... -- Regards, Ali Polatel -- 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/20100113/7f658183/attachment.pgp>
[notmuch] [RFC/PATCH] Add search-files command
This command can be used to integrate notmuch with other MUAs as a
searching client. The idea is simple, a simple script could get
search-terms as argument and create a "virtual" maildir which has
symbolic links to files output by search-files command. This is similar
to nmzmail.
---
Makefile.local |1 +
notmuch-client.h |3 +
notmuch-search-files.c | 107
notmuch.c | 13 ++
4 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 notmuch-search-files.c
diff --git a/Makefile.local b/Makefile.local
index 933ff4c..78bc25d 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -12,6 +12,7 @@ notmuch_client_srcs = \
notmuch-reply.c \
notmuch-restore.c \
notmuch-search.c\
+ notmuch-search-files.c \
notmuch-search-tags.c \
notmuch-setup.c \
notmuch-show.c \
diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..d505d30 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -96,6 +96,9 @@ int
notmuch_search_command (void *ctx, int argc, char *argv[]);
int
+notmuch_search_files_command (void *ctx, int argc, char *argv[]);
+
+int
notmuch_setup_command (void *ctx, int argc, char *argv[]);
int
diff --git a/notmuch-search-files.c b/notmuch-search-files.c
new file mode 100644
index 000..b48783a
--- /dev/null
+++ b/notmuch-search-files.c
@@ -0,0 +1,107 @@
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright ?? 2009 Carl Worth
+ *
+ * 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 3 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/ .
+ *
+ * Author: Ali Polatel
+ */
+
+#include "notmuch-client.h"
+
+static void
+do_search_files (notmuch_query_t *query)
+{
+notmuch_message_t *message;
+notmuch_messages_t *messages;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_has_more (messages);
+notmuch_messages_advance (messages))
+{
+ message = notmuch_messages_get (messages);
+ printf ("%s\n", notmuch_message_get_filename (message));
+ notmuch_message_destroy(message);
+}
+}
+
+int
+notmuch_search_files_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *notmuch;
+notmuch_query_t *query;
+char *query_str;
+char *opt;
+notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
+int i;
+
+for (i = 0; i < argc && argv[i][0] == '-'; i++) {
+ if (strcmp (argv[i], "--") == 0) {
+ i++;
+ break;
+ }
+if (STRNCMP_LITERAL (argv[i], "--sort=") == 0) {
+ opt = argv[i] + sizeof ("--sort=") - 1;
+ if (strcmp (opt, "oldest-first") == 0) {
+ sort = NOTMUCH_SORT_OLDEST_FIRST;
+ } else if (strcmp (opt, "newest-first") == 0) {
+ sort = NOTMUCH_SORT_NEWEST_FIRST;
+ } else {
+ fprintf (stderr, "Invalid value for --sort: %s\n", opt);
+ return 1;
+ }
+ } else {
+ fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
+ return 1;
+ }
+}
+
+argc -= i;
+argv += i;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+ return 1;
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+if (notmuch == NULL)
+ return 1;
+
+query_str = query_string_from_args (ctx, argc, argv);
+if (query_str == NULL) {
+ fprintf (stderr, "Out of memory.\n");
+ return 1;
+}
+if (*query_str == '\0') {
+ fprintf (stderr, "Error: notmuch search-files requires at least one
search term.\n");
+ return 1;
+}
+
+query = notmuch_query_create (notmuch, query_str);
+if (query == NULL) {
+ fprintf (stderr, "Out of memory\n");
+ return 1;
+}
+
+notmuch_query_set_sort (query, sort);
+
+do_search_files (query);
+
+notmuch_query_destroy (query);
+notmuch_database_close (notmuch);
+
+return 0;
+}
diff --git a/notmuch.c b/notmuch.c
index 87479f8..4907339 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -165,6 +165,19 @@ command_t commands[] = {
"\n"
"\t\tSee \"notmuch help search-terms\" for details of the search\n"
"\t\tterms
[notmuch] [RFC/PATCH] Add search-files command
Hi Ali,
On Wed, 13 Jan 2010 12:24:22 +0200, Ali Polatel wrote:
> This command can be used to integrate notmuch with other MUAs as a
> searching client. The idea is simple, a simple script could get
> search-terms as argument and create a "virtual" maildir which has
> symbolic links to files output by search-files command. This is similar
> to nmzmail.
> ---
> Makefile.local |1 +
> notmuch-client.h |3 +
> notmuch-search-files.c | 107
>
> notmuch.c | 13 ++
> 4 files changed, 124 insertions(+), 0 deletions(-)
> create mode 100644 notmuch-search-files.c
>
> diff --git a/Makefile.local b/Makefile.local
> index 933ff4c..78bc25d 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -12,6 +12,7 @@ notmuch_client_srcs = \
> notmuch-reply.c \
> notmuch-restore.c \
> notmuch-search.c\
> + notmuch-search-files.c \
> notmuch-search-tags.c \
> notmuch-setup.c \
> notmuch-show.c \
> diff --git a/notmuch-client.h b/notmuch-client.h
> index 77766de..d505d30 100644
> --- a/notmuch-client.h
> +++ b/notmuch-client.h
> @@ -96,6 +96,9 @@ int
> notmuch_search_command (void *ctx, int argc, char *argv[]);
>
> int
> +notmuch_search_files_command (void *ctx, int argc, char *argv[]);
> +
> +int
> notmuch_setup_command (void *ctx, int argc, char *argv[]);
>
> int
> diff --git a/notmuch-search-files.c b/notmuch-search-files.c
> new file mode 100644
> index 000..b48783a
> --- /dev/null
> +++ b/notmuch-search-files.c
> @@ -0,0 +1,107 @@
> +/* notmuch - Not much of an email program, (just index and search)
> + *
> + * Copyright ? 2009 Carl Worth
I almost certainly should not be speaking in the name of Carl, but a
few weeks ago he replied with the following words to a message which
somehow raised the discussion of copyright holding in notmuch source
code:
"Please feel free to retain your own copyright. I certainly don't
deserve anything being assigned to me."
The message-id of his reply is: 873a34tf8b.fsf at yoom.home.cworth.org,
just in the case you want to check the context in which it occurred.
> + *
> + * 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 3 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/ .
> + *
> + * Author: Ali Polatel
> + */
> +
> +#include "notmuch-client.h"
> +
> +static void
> +do_search_files (notmuch_query_t *query)
> +{
> +notmuch_message_t *message;
> +notmuch_messages_t *messages;
> +
> +for (messages = notmuch_query_search_messages (query);
> + notmuch_messages_has_more (messages);
> + notmuch_messages_advance (messages))
> +{
> + message = notmuch_messages_get (messages);
> + printf ("%s\n", notmuch_message_get_filename (message));
> + notmuch_message_destroy(message);
> +}
> +}
> +
> +int
> +notmuch_search_files_command (void *ctx, int argc, char *argv[])
> +{
> +notmuch_config_t *config;
> +notmuch_database_t *notmuch;
> +notmuch_query_t *query;
> +char *query_str;
> +char *opt;
> +notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
> +int i;
> +
> +for (i = 0; i < argc && argv[i][0] == '-'; i++) {
> + if (strcmp (argv[i], "--") == 0) {
> + i++;
> + break;
> + }
> +if (STRNCMP_LITERAL (argv[i], "--sort=") == 0) {
> + opt = argv[i] + sizeof ("--sort=") - 1;
> + if (strcmp (opt, "oldest-first") == 0) {
> + sort = NOTMUCH_SORT_OLDEST_FIRST;
> + } else if (strcmp (opt, "newest-first") == 0) {
> + sort = NOTMUCH_SORT_NEWEST_FIRST;
> + } else {
> + fprintf (stderr, "Invalid value for --sort: %s\n", opt);
> + return 1;
> + }
> + } else {
> + fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
> + return 1;
> + }
> +}
> +
> +argc -= i;
> +argv += i;
> +
> +config = notmuch_config_open (ctx, NULL, NULL);
> +if (config == NULL)
> + return 1;
> +
> +notmuch = notmuch_database_open (notmuch_config_get_database_path
> (config),
> + NOTMUCH_DATABASE_MODE_READ_ONLY);
> +if (notmuch == NULL)
> + return 1;
> +
> +query_str = query_string_from_args (ctx, argc, argv);
> +if (query_str == NULL) {
> + fprintf (stderr, "Out of memory.\n");
> +
[notmuch] [RFC/PATCH] Add search-files command
Fernando Carrijo yazm??:
> Hi Ali,
Hey Fernando,
> On Wed, 13 Jan 2010 12:24:22 +0200, Ali Polatel wrote:
> > diff --git a/notmuch-search-files.c b/notmuch-search-files.c
> > new file mode 100644
> > index 000..b48783a
> > --- /dev/null
> > +++ b/notmuch-search-files.c
> > @@ -0,0 +1,107 @@
> > +/* notmuch - Not much of an email program, (just index and search)
> > + *
> > + * Copyright ? 2009 Carl Worth
>
> I almost certainly should not be speaking in the name of Carl, but a
> few weeks ago he replied with the following words to a message which
> somehow raised the discussion of copyright holding in notmuch source
> code:
>
> "Please feel free to retain your own copyright. I certainly don't
>deserve anything being assigned to me."
>
> The message-id of his reply is: 873a34tf8b.fsf at yoom.home.cworth.org,
> just in the case you want to check the context in which it occurred.
>
Thanks, I don't really care about who owns the copyright as long as it's
open source but I'll change it if that's what Carl wishes.
> > +if (*query_str == '\0') {
> > + fprintf (stderr, "Error: notmuch search-files requires at least one
> > search term.\n");
>
> Could we break this line so that it did not go beyond the column limit
> set by the coding conventions? Maybe we should go one step further and
> import the file CODING_STYLE from cairo into notmuch's repository.
>
Sure, I didn't know much about the coding style and as you said there's
no document about it in notmuch's repository.
> > + return 1;
> > +}
> > +
> > +query = notmuch_query_create (notmuch, query_str);
> > +if (query == NULL) {
> > + fprintf (stderr, "Out of memory\n");
> > + return 1;
> > +}
> > +
> > +notmuch_query_set_sort (query, sort);
> > +
> > +do_search_files (query);
> > +
> > +notmuch_query_destroy (query);
> > +notmuch_database_close (notmuch);
>
> It is not something of major importance, but I realized that the
> function notmuch_config_close is only being called when notmuch is
> executed with no arguments. As we know, the kernel shall close all
> open file descriptors upon program termination, but wouldn't it be
> better if we did it explicitly? Or did I overlook something?
>
Nope, it's good coding practise to free all resources before exit, I
didn't do it for config because neither the search command does it.
I'll send an updated patch soonish and I'll also send a separate patch
for notmuch-search.c as well.
> Kind regards,
> Fernando Carrijo.
>
--
Regards,
Ali Polatel
-- 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/20100113/3fa66c75/attachment-0001.pgp>
[notmuch] [RFC/PATCH v2] Add search-files command
This command can be used to integrate notmuch with other MUAs as a
searching client. The idea is simple, a simple script could get
search-terms as argument and create a "virtual" maildir which has
symbolic links to files output by search-files command. This is similar
to nmzmail.
Version 2:
- Update copyright
- Respect coding style about long lines
- Free config structure on exit
---
Makefile.local |1 +
notmuch-client.h |3 +
notmuch-search-files.c | 109
notmuch.c | 13 ++
4 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644 notmuch-search-files.c
diff --git a/Makefile.local b/Makefile.local
index 933ff4c..78bc25d 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -12,6 +12,7 @@ notmuch_client_srcs = \
notmuch-reply.c \
notmuch-restore.c \
notmuch-search.c\
+ notmuch-search-files.c \
notmuch-search-tags.c \
notmuch-setup.c \
notmuch-show.c \
diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..d505d30 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -96,6 +96,9 @@ int
notmuch_search_command (void *ctx, int argc, char *argv[]);
int
+notmuch_search_files_command (void *ctx, int argc, char *argv[]);
+
+int
notmuch_setup_command (void *ctx, int argc, char *argv[]);
int
diff --git a/notmuch-search-files.c b/notmuch-search-files.c
new file mode 100644
index 000..7b6d14d
--- /dev/null
+++ b/notmuch-search-files.c
@@ -0,0 +1,109 @@
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright ?? 2010 Ali Polatel
+ *
+ * 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 3 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/ .
+ *
+ * Author: Ali Polatel
+ */
+
+#include "notmuch-client.h"
+
+static void
+do_search_files (notmuch_query_t *query)
+{
+notmuch_message_t *message;
+notmuch_messages_t *messages;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_has_more (messages);
+notmuch_messages_advance (messages))
+{
+ message = notmuch_messages_get (messages);
+ printf ("%s\n", notmuch_message_get_filename (message));
+ notmuch_message_destroy(message);
+}
+}
+
+int
+notmuch_search_files_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *notmuch;
+notmuch_query_t *query;
+char *query_str;
+char *opt;
+notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
+int i;
+
+for (i = 0; i < argc && argv[i][0] == '-'; i++) {
+ if (strcmp (argv[i], "--") == 0) {
+ i++;
+ break;
+ }
+if (STRNCMP_LITERAL (argv[i], "--sort=") == 0) {
+ opt = argv[i] + sizeof ("--sort=") - 1;
+ if (strcmp (opt, "oldest-first") == 0) {
+ sort = NOTMUCH_SORT_OLDEST_FIRST;
+ } else if (strcmp (opt, "newest-first") == 0) {
+ sort = NOTMUCH_SORT_NEWEST_FIRST;
+ } else {
+ fprintf (stderr, "Invalid value for --sort: %s\n", opt);
+ return 1;
+ }
+ } else {
+ fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
+ return 1;
+ }
+}
+
+argc -= i;
+argv += i;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+ return 1;
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+if (notmuch == NULL)
+ return 1;
+
+query_str = query_string_from_args (ctx, argc, argv);
+if (query_str == NULL) {
+ fprintf (stderr, "Out of memory.\n");
+ return 1;
+}
+if (*query_str == '\0') {
+ fprintf (stderr, "Error: notmuch search-files requires"
+" at least one search term.\n");
+ return 1;
+}
+
+query = notmuch_query_create (notmuch, query_str);
+if (query == NULL) {
+ fprintf (stderr, "Out of memory\n");
+ return 1;
+}
+
+notmuch_query_set_sort (query, sort);
+
+do_search_files (query);
+
+notmuch_config_close (config);
+notmuch_query_destroy (query);
+notmuch_database_close (notmuch);
+
+return 0;
+}
diff --git a/notmuch.c b/notmuch.c
index 87479f8..4907339 100644
---
[notmuch] [PATCH] Import CODING_STYLE from cairo
A good way to let new contributors know how to contribute :)
---
CODING_STYLE | 291 ++
1 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 CODING_STYLE
diff --git a/CODING_STYLE b/CODING_STYLE
new file mode 100644
index 000..95ceac0
--- /dev/null
+++ b/CODING_STYLE
@@ -0,0 +1,291 @@
+Cairo coding style.
+
+This document is intended to be a short description of the preferred
+coding style for the cairo source code. Good style requires good
+taste, which means this can't all be reduced to automated rules, and
+there are exceptions.
+
+We want the code to be easy to understand and maintain, and consistent
+style plays an important part in that, even if some of the specific
+details seem trivial. If nothing else, this document gives a place to
+put consistent answers for issues that would otherwise be arbitrary.
+
+Most of the guidelines here are demonstrated by examples, (which means
+this document is quicker to read than it might appear given its
+length). Most of the examples are positive examples that you should
+imitate. The few negative examples are clearly marked with a comment
+of /* Yuck! */. Please don't submit code to cairo that looks like any
+of these.
+
+Indentation
+---
+Each new level is indented 4 more spaces than the previous level:
+
+ if (condition)
+ do_something ();
+
+This may be achieved with space characters or a combination of tab
+characters and space characters. It may not be achieved with tab
+characters exclusively (see below).
+
+Tab characters
+--
+The tab character must always be interpreted according to its
+traditional meaning:
+
+ Advance to the next column which is a multiple of 8.
+
+With this definition, even levels of indentation can be achieved with
+a sequence of tab characters, while odd levels of indentation may
+begin with a sequence of tab character but must end with 4 space
+characters.
+
+Some programmers have been misled by certain text editors into
+thinking that 4-space indentation can be achieved with tab characters
+exclusively by changing the meaning of tab character to be "advance to
+the next column which is a multiple of 4". Code formatted in this way,
+making an assumption of a fictitious 4-character-tab will not be
+accepted into cairo.
+
+The rationale here is that tabs are used in the code for lining things
+up other than indentation, (see the Whitespace section below), and
+changing the interpretation of tab from its traditional meaning will
+break this alignment.
+
+Braces
+--
+Most of the code in cairo uses bracing in the style of K:
+
+ if (condition) {
+ do_this ();
+ do_that ();
+ } else {
+ do_the_other ();
+ }
+
+but some of the code uses an alternate style:
+
+ if (condition)
+ {
+ do_this ();
+ do_that ();
+ }
+ else
+ {
+ do_the_other ();
+ }
+
+and that seems just fine. We won't lay down any strict rule on this
+point, (though there should be some local consistency). If you came
+here hoping to find some guidance, then use the first form above.
+
+If all of the substatements of an if statement are single statements,
+the optional braces should not usually appear:
+
+ if (condition)
+ do_this ();
+ else
+ do_that ();
+
+But the braces are mandatory when mixing single statement and compound
+statements in the various clauses. For example, do not do this:
+
+ if (condition) {
+ do_this ();
+ do_that ();
+ } else /* Yuck! */
+ do_the_other ();
+
+And of course, there are exceptions for when the code just looks
+better with the braces:
+
+ if (condition) {
+ /* Note that we have to be careful here. */
+ do_something_dangerous (with_care);
+ }
+
+ if (condition &&
+ other_condition &&
+ yet_another)
+ {
+ do_something ();
+ }
+
+And note that this last example also shows a situation in which the
+opening brace really needs to be on its own line. The following looks awful:
+
+ if (condition &&
+ other_condition &&
+ yet_another) { /* Yuck! */
+ do_something ();
+ }
+
+As we said above, legible code that is easy to understand and maintain
+is the goal, not adherence to strict rules.
+
+Whitespace
+--
+Separate logically distinct chunks with a single newline. This
+obviously applies between functions, but also applies within a
+function or block and can even be used to good effect within a
+structure definition:
+
+ struct _cairo_gstate {
+ cairo_operator_t op;
+
+ double tolerance;
+
+ /* stroke style */
+ double line_width;
+ cairo_line_cap_t line_cap;
+ cairo_line_join_t line_join;
+ double miter_limit;
+
+
[notmuch] [PATCH] Import CODING_STYLE from cairo
On Wed, 13 Jan 2010 15:40:42 +0200, Ali Polatel wrote:
> A good way to let new contributors know how to contribute :)
Not a bad idea. Also nice would be a style definition for emacs.
I started, but did not get very far or even have much confidence it what
I did do :)
(setq notmuch-c-style
'("linux"
(c-basic-offset . 4)))
(c-add-style "notmuch" notmuch-c-style)
[notmuch] [PATCH] Import CODING_STYLE from cairo
Hi Ali,
On Wed, 13 Jan 2010 15:40:42 +0200, Ali Polatel wrote:
> A good way to let new contributors know how to contribute :)
> ---
> CODING_STYLE | 291
> ++
> 1 files changed, 291 insertions(+), 0 deletions(-)
> create mode 100644 CODING_STYLE
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> new file mode 100644
> index 000..95ceac0
> --- /dev/null
> +++ b/CODING_STYLE
> @@ -0,0 +1,291 @@
> +Cairo coding style.
> +
> +This document is intended to be a short description of the preferred
> +coding style for the cairo source code. Good style requires good
> +taste, which means this can't all be reduced to automated rules, and
> +there are exceptions.
Maybe s/cairo/notmuch/ ?
> +
> +We want the code to be easy to understand and maintain, and consistent
> +style plays an important part in that, even if some of the specific
> +details seem trivial. If nothing else, this document gives a place to
> +put consistent answers for issues that would otherwise be arbitrary.
> +
> +Most of the guidelines here are demonstrated by examples, (which means
> +this document is quicker to read than it might appear given its
> +length). Most of the examples are positive examples that you should
> +imitate. The few negative examples are clearly marked with a comment
> +of /* Yuck! */. Please don't submit code to cairo that looks like any
> +of these.
> +
> +Indentation
> +---
> +Each new level is indented 4 more spaces than the previous level:
> +
> + if (condition)
> + do_something ();
> +
> +This may be achieved with space characters or a combination of tab
> +characters and space characters. It may not be achieved with tab
> +characters exclusively (see below).
> +
> +Tab characters
> +--
> +The tab character must always be interpreted according to its
> +traditional meaning:
> +
> + Advance to the next column which is a multiple of 8.
> +
> +With this definition, even levels of indentation can be achieved with
> +a sequence of tab characters, while odd levels of indentation may
> +begin with a sequence of tab character but must end with 4 space
> +characters.
> +
> +Some programmers have been misled by certain text editors into
> +thinking that 4-space indentation can be achieved with tab characters
> +exclusively by changing the meaning of tab character to be "advance to
> +the next column which is a multiple of 4". Code formatted in this way,
> +making an assumption of a fictitious 4-character-tab will not be
> +accepted into cairo.
> +
> +The rationale here is that tabs are used in the code for lining things
> +up other than indentation, (see the Whitespace section below), and
> +changing the interpretation of tab from its traditional meaning will
> +break this alignment.
> +
> +Braces
> +--
> +Most of the code in cairo uses bracing in the style of K:
> +
> + if (condition) {
> + do_this ();
> + do_that ();
> + } else {
> + do_the_other ();
> + }
> +
> +but some of the code uses an alternate style:
> +
> + if (condition)
> + {
> + do_this ();
> + do_that ();
> + }
> + else
> + {
> + do_the_other ();
> + }
> +
> +and that seems just fine. We won't lay down any strict rule on this
> +point, (though there should be some local consistency). If you came
> +here hoping to find some guidance, then use the first form above.
> +
> +If all of the substatements of an if statement are single statements,
> +the optional braces should not usually appear:
> +
> + if (condition)
> + do_this ();
> + else
> + do_that ();
> +
> +But the braces are mandatory when mixing single statement and compound
> +statements in the various clauses. For example, do not do this:
> +
> + if (condition) {
> + do_this ();
> + do_that ();
> + } else /* Yuck! */
> + do_the_other ();
> +
> +And of course, there are exceptions for when the code just looks
> +better with the braces:
> +
> + if (condition) {
> + /* Note that we have to be careful here. */
> + do_something_dangerous (with_care);
> + }
> +
> + if (condition &&
> + other_condition &&
> + yet_another)
> + {
> + do_something ();
> + }
> +
> +And note that this last example also shows a situation in which the
> +opening brace really needs to be on its own line. The following looks awful:
> +
> + if (condition &&
> + other_condition &&
> + yet_another) { /* Yuck! */
> + do_something ();
> + }
> +
> +As we said above, legible code that is easy to understand and maintain
> +is the goal, not adherence to strict rules.
> +
> +Whitespace
> +--
> +Separate logically distinct chunks with a single newline. This
> +obviously applies between functions, but also applies within a
> +function or block and can even be used to good effect within a
>
[notmuch] [RFC/PATCH v2] Add search-files command
On Wed, Jan 13, 2010 at 03:17:41PM +0200, Ali Polatel wrote: > This command can be used to integrate notmuch with other MUAs as a > searching client. The idea is simple, a simple script could get > search-terms as argument and create a "virtual" maildir which has > symbolic links to files output by search-files command. This is similar > to nmzmail. Hi, Ali. I was also recently asking about a way to output just the file names of message resulting from searches. This is an important feature for handling deleting and moving in mail clients as well. I believe that Carl said this would be easier once he applied the JSON output patches that are in the queue right now. Hopefully we'll see those soon. Personally I think the right way to implement this from a UI perspective would be to just have an output filter for the 'search' subcommand, something like: notmuch search --output=filename ... If output formatting was well enough supported one could even imagine getting rid of the 'show' subcommand in favor of just the 'search' subcommand with output formatting options. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100113/32ce815c/attachment.pgp>
[notmuch] Idea for storing tags
On Tue, 12 Jan 2010 11:19:09 +1300, martin f krafft wrote: > 1. External database, which has the downside of not being >synchronisable with standard IMAP, like the rest of your mail >(assuming you use IMAP). Also, it's possible for mailstore and >database to get out of sync. Yes. This approach requires some external means of synchronizing the tags from one system to another. I don't understand what it would mean to have the mailstore and the database out of synch here. This approach doesn't have the tags in the mailstore by definition, right? > How about using pseudo-mails stored in Maildir and synchronised by > IMAP? E.g. every folder could have a subfolder .TAGS and if we find > a way to smartly pair messages between parent and subfolder, we'd > have a tag store alongside the mailstore it refers to, but without > the danger of leakage, and without having to rewrite messages. ... > Anyway, the idea is out now. Thoughts? There are a couple of problems that I don't see addressed at all with this approach. The first is that there's not a one-to-one mapping between messages and files in the mail store. (I'm CCed on a lot of list mail meaning that I have multiple files in my mail store for a single message.) Second, the only reason I would be interested in synchronizing mail between two systems is so that I could manipulate the tag data in multiple places, (that is, remove the "unread" tag whether on my network-disconnected laptop or via web-mail when away from my laptop). Using imap for synchronizing a file of tags within the mail store gives you no mechanism for doing any sort of conflict resolution, right? (Which I think in almost all cases is going to be quite trivial if there's a chance for a program to resolve it.) So it sounds to me like we're going to need *something* custom for doing the synchronization, (to handle modifications on both ends). At which point there's only disadvantages to keeping the data inside the mailstore, and there's also no disadvantage left to keeping the data inside a database. [*] [*] Though, I think a plain-text file with tags managed with something like git (and perhaps a custom merger) could save a lot of work. Or perhaps a plain-text journal of tag manipulations on either end that could be replayed on the other. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100113/32ec7928/attachment.pgp>
[notmuch] Idea for storing tags
On Wed, 13 Jan 2010 00:39:14 -0500, Scott Morrison wrote: > > Maybe a better approach would be content addressing (see below). > > Content hashing -- good Idea (& not something that has hit me before) > -- better than Message-Id as I believe there are still some MUA /MTAs > that allow messages without message ids. The only potential issue > with this is that it is critical then to preserve the message source > against encoding changes though that shouldn't be too hard to avoid. Another problem with content-based naming for messages is that most of the messages in my mail store that I consider duplicates don't actually have identical content. (One is sent directly to me via CC and the other is sent by the mailing-list software *after* appending a footer to the message.) That said, notmuch already does use a sha-1 sum as the message identifier for any message that does not have a valid Message-ID header. So there's definitely a place for this. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100113/3d378b4d/attachment.pgp>
