[notmuch] New to the list
Hi all, I have subscribed to the list. As suggested by the welcome message, I am introducing myself. My name is Israel Herraiz, and I have done a couple of contributions to Sup, the probably well-known here e-mail client. "Not much" sounds interesting, and I wonder whether it could be integrated with the views of Sup (inbox, threads, etc). So I have subscribed to the list to keep an eye on what's going on here. I have just heard of "Not much". I have not even tried to download the code yet. Cheers, Israel
[notmuch] What a great idea!
On Tue, Nov 17, 2009 at 11:35 PM, Jan Janak wrote: > Hello, > > First of all, notmuch is a wonderful idea, both the cmdline tool and > the emacs interface! Thanks a lot for writing it, I was really excited > when I read the announcement today. > > Have you considered sending an announcement to the org-mode mailing list? > http://org-mode.org Sorry, wrong URL, the correct one is: http://orgmode.org > Various ways of searching/referencing emails from emacs were discussed > there several times and none of them were as elegant as notmuch (not > even close). Maybe notmuch would attract some of the developers > there.. -- Jan
[notmuch] What a great idea!
Hello, First of all, notmuch is a wonderful idea, both the cmdline tool and the emacs interface! Thanks a lot for writing it, I was really excited when I read the announcement today. Have you considered sending an announcement to the org-mode mailing list? http://org-mode.org Various ways of searching/referencing emails from emacs were discussed there several times and none of them were as elegant as notmuch (not even close). Maybe notmuch would attract some of the developers there.. -- Jan
[notmuch] [PATCH] Older versions of install do not support -C.
Do not use -C cmdline option of install, older versions, commonly found in distributions like Debian, do not seem to support it. Running make install on such systems (tested on Debian Lenny) fails. Signed-off-by: Jan Janak --- Makefile.local |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.local b/Makefile.local index f824bed..f51f1d1 100644 --- a/Makefile.local +++ b/Makefile.local @@ -27,11 +27,11 @@ install: all notmuch.1.gz for d in $(DESTDIR)$(prefix)/bin/ $(DESTDIR)$(prefix)/share/man/man1 \ $(DESTDIR)/etc/bash_completion.d/ ; \ do \ - install -C -d $$d ; \ + install -d $$d ; \ done ; - install -C notmuch $(DESTDIR)$(prefix)/bin/ - install -C -m0644 notmuch.1.gz $(DESTDIR)$(prefix)/share/man/man1/ - install -C notmuch-completion.bash \ + install notmuch $(DESTDIR)$(prefix)/bin/ + install -m0644 notmuch.1.gz $(DESTDIR)$(prefix)/share/man/man1/ + install notmuch-completion.bash \ $(DESTDIR)/etc/bash_completion.d/notmuch SRCS := $(SRCS) $(notmuch_client_srcs) -- 1.6.3.3
[notmuch] Mac OS X/Darwin compatibility issues
On Wed, 18 Nov 2009 14:14:27 +0800, Jjgod Jiang wrote: > Hi, > > On Wed, Nov 18, 2009 at 1:45 PM, Alexander Botero-Lowry > wrote: > > for getline do you mind trying #define _GNU_SOURCE 1 > > before #include in the offending files? The FreeBSD man pages > > mentions that as a way of enabling the GNU version of getline(). > > It seems even _GNU_SOURCE is defined, getline is still not present. > the C lib in Mac OS X simply doesn't have it. See also [1]. > Alas. Since it's ostensibly based on the FreeBSD one, I figured there was a chance that would fix the problem. :/
[notmuch] Mac OS X/Darwin compatibility issues
On Wed, 18 Nov 2009 11:50:17 +0800, Jjgod Jiang wrote:
> Hi,
>
> When I tried to compile notmuch under Mac OS X 10.6, several issues
> arisen:
>
> 1. g++ reports 'warning: command line option "-Wmissing-declarations"
> is valid for C/ObjC but not for C++'
>
I got that too. I presume it's newly supported in GCC4.4?
> 3. Several errors about missing GNU extensions like getline() and strndup():
>
strndup from V8:
char* strndup(char* str, size_t n) {
// Stupid implementation of strndup since macos isn't born with
// one.
size_t len = strlen(str);
if (len <= n)
return StrDup(str);
char* result = new char[n+1];
size_t i;
for (i = 0; i <= n; i++)
result[i] = str[i];
result[i] = '\0';
return result;
}
> warning: implicit declaration of function ?getline?
> error: ?strndup? was not declared in this scope
>
for getline do you mind trying #define _GNU_SOURCE 1
before #include in the offending files? The FreeBSD man pages
mentions that as a way of enabling the GNU version of getline().
Alex
[notmuch] [PATCH 2/2] Include to get uint32_t in C++ file with gcc 4.4
Signed-off-by: Mikhail Gusarov --- lib/message.cc |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index 72c350f..a4b090b 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -21,6 +21,8 @@ #include "notmuch-private.h" #include "database-private.h" +#include + #include #include -- 1.6.3.3
[notmuch] [PATCH 1/2] Close message file after parsing message headers
Keeping unused files open helps to see "Too many open files" often.
Signed-off-by: Mikhail Gusarov
---
lib/message-file.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 8a3f8ee..197ab01 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -325,6 +325,11 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
return decoded_value;
}
+if (message->parsing_finished) {
+fclose (message->file);
+message->file = NULL;
+}
+
if (message->line)
free (message->line);
message->line = NULL;
--
1.6.3.3
[notmuch] Link to mailing list archives ?
The link[1] provided on the list page[2] is broken: [1] http://notmuchmail.org/pipermail/notmuch/ [2] http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] "notmuch help" outputs to stderr?
> I've attached a patch that lets usage() take a FILE * argument so that
> you can output to stderr in response to usage errors, and stdout in
> response to an explicit request.
Whoops, missed a couple of stderr's in that last patch. New one
attached.
--
Lars Kellogg-Stedman
Senior Technologist, Computing and Information Technology
Harvard University School of Engineering and Applied Sciences
-- next part --
diff --git a/notmuch.c b/notmuch.c
index c47e640..446c810 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -157,23 +157,23 @@ command_t commands[] = {
};
static void
-usage (void)
+usage (FILE *out)
{
command_t *command;
unsigned int i;
-fprintf (stderr, "Usage: notmuch [args...]\n");
-fprintf (stderr, "\n");
-fprintf (stderr, "Where and [args...] are as follows:\n");
-fprintf (stderr, "\n");
+fprintf (out, "Usage: notmuch [args...]\n");
+fprintf (out, "\n");
+fprintf (out, "Where and [args...] are as follows:\n");
+fprintf (out, "\n");
for (i = 0; i < ARRAY_SIZE (commands); i++) {
command = &commands[i];
- fprintf (stderr, "\t%s\t%s\n\n", command->name, command->summary);
+ fprintf (out, "\t%s\t%s\n\n", command->name, command->summary);
}
-fprintf (stderr, "Use \"notmuch help \" for more details on each
command.\n\n");
+fprintf (out, "Use \"notmuch help \" for more details on each
command.\n\n");
}
static int
@@ -183,8 +183,8 @@ notmuch_help_command (unused (void *ctx), int argc, char
*argv[])
unsigned int i;
if (argc == 0) {
- fprintf (stderr, "The notmuch mail system.\n\n");
- usage ();
+ fprintf (stdout, "The notmuch mail system.\n\n");
+ usage (stdout);
return 0;
}
@@ -192,8 +192,8 @@ notmuch_help_command (unused (void *ctx), int argc, char
*argv[])
command = &commands[i];
if (strcmp (argv[0], command->name) == 0) {
- fprintf (stderr, "Help for \"notmuch %s\":\n\n", argv[0]);
- fprintf (stderr, "\t%s\t%s\n\n%s\n\n", command->name,
+ fprintf (stdout, "Help for \"notmuch %s\":\n\n", argv[0]);
+ fprintf (stdout, "\t%s\t%s\n\n%s\n\n", command->name,
command->summary, command->documentation);
return 0;
}
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091117/8c0e4dc3/attachment.pgp>
[notmuch] "notmuch help" outputs to stderr?
I'm just noticing that 'notmuch help ...' outputs to stderr, which
isn't terribly intuitive. For example, the obvious invocation:
notmuch help | less
...isn't terribly helpful.
I've attached a patch that lets usage() take a FILE * argument so that
you can output to stderr in response to usage errors, and stdout in
response to an explicit request.
--
Lars Kellogg-Stedman
Senior Technologist, Computing and Information Technology
Harvard University School of Engineering and Applied Sciences
-- next part --
diff --git a/notmuch.c b/notmuch.c
index c47e640..a35cb99 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -157,23 +157,23 @@ command_t commands[] = {
};
static void
-usage (void)
+usage (FILE *out)
{
command_t *command;
unsigned int i;
-fprintf (stderr, "Usage: notmuch [args...]\n");
-fprintf (stderr, "\n");
-fprintf (stderr, "Where and [args...] are as follows:\n");
-fprintf (stderr, "\n");
+fprintf (out, "Usage: notmuch [args...]\n");
+fprintf (out, "\n");
+fprintf (out, "Where and [args...] are as follows:\n");
+fprintf (out, "\n");
for (i = 0; i < ARRAY_SIZE (commands); i++) {
command = &commands[i];
- fprintf (stderr, "\t%s\t%s\n\n", command->name, command->summary);
+ fprintf (out, "\t%s\t%s\n\n", command->name, command->summary);
}
-fprintf (stderr, "Use \"notmuch help \" for more details on each
command.\n\n");
+fprintf (out, "Use \"notmuch help \" for more details on each
command.\n\n");
}
static int
@@ -183,8 +183,8 @@ notmuch_help_command (unused (void *ctx), int argc, char
*argv[])
unsigned int i;
if (argc == 0) {
- fprintf (stderr, "The notmuch mail system.\n\n");
- usage ();
+ fprintf (stdout, "The notmuch mail system.\n\n");
+ usage (stdout);
return 0;
}
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091117/03ed852d/attachment.pgp>
[notmuch] Working with Maildir storage?
> I've also pushed a slightly more complicated (and complete) fix to my > private notmuch repository The version of lib/messages.cc in your repo doesn't build because it's missing "#include " (for the uint32_t on line 466). -- Lars Kellogg-Stedman Senior Technologist, Computing and Information Technology Harvard University School of Engineering and Applied Sciences -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/b069f470/attachment.pgp>
[notmuch] archive
Just subscribed, I'd like to catch up on the previous postings, but the archive link seems to be bogus? Thanks, Aron
[notmuch] archive
On Tue, 17 Nov 2009 18:21:38 -0500, Aron Griffis wrote: > Just subscribed, I'd like to catch up on the previous postings, > but the archive link seems to be bogus? Yeah, the archive appears broken and will need to wait until Carl arrives in Barcelona to get fixed. -- keith.packard at intel.com
[notmuch] Introducing myself
On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro wrote: > Some time ago I thought > about doing something like Not Much and in fact I played a bit with the > Python+Xapian and the Python+Whoosh combinations, because I find relaxing > to code things in Python when I am not working and also it is installed > by default on most distribution. I got to have some mailboxes indexed and > basic searching working a couple of months ago. Sup certainly started a lot of people thinking... > Also, I would like to share one idea I had in mind, that you might find > interesting: One thing I have found very annoying is having to re-tag my > mail when the indexes get b0rked (it happened a couple of times to me while > using Sup), so I was planning to mails as read/unread and adding the tags > not just to the index, but to the mail text itself, e.g. by adding a > "X-Tags" header field or by reusing the "Keywords" one. Easier than that, notmuch (and sup too), provide a 'dump' command which just lists all of the message IDs and their associated tags. Makes saving tags easy and doesn't involve rewriting messages. I do this once a day just before my computer is backed up to an external drive. If the index is destroyed, you can reindex the messages and then reapply all of the tags with 'notmuch restore'. -- keith.packard at intel.com
[notmuch] New to the list
On Tue, 17 Nov 2009 23:57:18 +0100, Israel Herraiz wrote: > "Not much" sounds interesting, and I wonder whether it could be > integrated with the views of Sup (inbox, threads, etc). So I have > subscribed to the list to keep an eye on what's going on here. We've tried to clone much of the sup UI inside emacs, including the inbox and threaded message presentation. Of course, we had to "improve" it a bit, as much due to the differences between curses and emacs as due to personal preferences... -keith
[notmuch] [PATCH] Error out if no query is supplied to search instead of going into an infinite loop
In this case error out when no query is supplied. There seems to be an infinite-loop casued by i think notmuch_query_search_threads having an exception: A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND A Xapian exception occurred: Syntax: AND I'll look into that bug specifically a bit later. It might be better to do a usage instead of just throwing an error here? alex -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/b95e96cd/attachment.htm> -- next part -- A non-text attachment was scrubbed... Name: 0001-Error-out-if-no-query-is-supplied-to-search-instead-.patch Type: application/octet-stream Size: 793 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/b95e96cd/attachment.obj>
[notmuch] Working with Maildir storage?
> See the patch just posted here. Is the list archived anywhere? The obvious archives (http://notmuchmail.org/pipermail/notmuch/) aren't available, and I think I subscribed too late to get the patch (I only just saw the discussion about it). It doesn't look like the patch is in git yet. -- Lars -- Lars Kellogg-Stedman Senior Technologist, Computing and Information Technology Harvard University School of Engineering and Applied Sciences -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/5bed6654/attachment.pgp>
[notmuch] Working with Maildir storage?
I saw the LWN article and decided to take a look at notmuch. I'm currently using mutt and mairix to index and read a collection of Maildir mail folders (around 40,000 messages total). notmuch indexed the messages without complaint, but my attempt at searching bombed out. Running, for example: notmuch search storage Resulted in 4604 lines of errors along the lines of: Error opening /home/lars/Mail/read-messages.2008/cur/1246413773.24928_27334.hostname,U=3026:2,S: Too many open files I'm curious if this is expected behavior (i.e., notmuch does not work with Maildir) or if something else is going on. Cheers, -- Lars Kellogg-Stedman Senior Technologist, Computing and Information Technology Harvard University School of Engineering and Applied Sciences -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/0bc8f9bd/attachment.pgp>
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
When closing a thread view, mark the thread as archived by removing the "inbox" tag, and for the 'x' variant, the "unread" tag as well, then kill the buffer and update the search window view as well. This makes 'x' much the same as 'a', but instead of taking you to the next message, it takes you back to the search window instead. Signed-off-by: Keith Packard --- notmuch.el | 86 ++- 1 files changed, 67 insertions(+), 19 deletions(-) diff --git a/notmuch.el b/notmuch.el index 638d49d..7b0d72c 100644 --- a/notmuch.el +++ b/notmuch.el @@ -31,8 +31,8 @@ ; Will be much preferable to switch to direct manipulation for ; toggling visibility of these components. Probably using ; overlays-at to query and manipulate the current overlay. -(define-key map "a" 'notmuch-show-archive-thread) -(define-key map "A" 'notmuch-show-mark-read-then-archive-thread) +(define-key map "a" 'notmuch-show-mark-read-archive-thread-next-thread) +(define-key map "A" 'notmuch-show-archive-thread-next-thread) (define-key map "b" 'notmuch-show-toggle-body-read-visible) (define-key map "c" 'notmuch-show-toggle-citations-visible) (define-key map "h" 'notmuch-show-toggle-headers-visible) @@ -47,7 +47,8 @@ (define-key map "s" 'notmuch-show-toggle-signatures-visible) (define-key map "v" 'notmuch-show-view-all-mime-parts) (define-key map "w" 'notmuch-show-view-raw-message) -(define-key map "x" 'kill-this-buffer) +(define-key map "x" 'notmuch-show-mark-read-archive-thread-kill-buffer) +(define-key map "X" 'notmuch-show-archive-thread-kill-buffer) (define-key map "+" 'notmuch-show-add-tag) (define-key map "-" 'notmuch-show-remove-tag) (define-key map (kbd "DEL") 'notmuch-show-rewind) @@ -183,7 +184,33 @@ Unlike builtin `next-line' this version accepts no arguments." (cons (notmuch-show-get-message-id) nil))) (notmuch-show-set-tags (sort (set-difference tags toremove :test 'string=) 'string<)) -(defun notmuch-show-archive-thread-maybe-mark-read (markread) +(defun notmuch-show-next-thread (markread) + (let ((parent-buffer notmuch-show-parent-buffer)) +(kill-this-buffer) +(if parent-buffer + (progn + (switch-to-buffer parent-buffer) + (forward-line) + (notmuch-search-show-thread) + +(defun notmuch-delete-tags (to-remove from) + (if to-remove + (delete (car to-remove) (notmuch-delete-tags (cdr to-remove) from)) +from)) + +(defun notmuch-kill-message-buffer (markread) + (let ((parent-buffer notmuch-show-parent-buffer)) +(kill-this-buffer) +(if parent-buffer + (progn + (switch-to-buffer parent-buffer) + (let ((tags (notmuch-search-get-tags))) + (setq tags (delete "inbox" tags)) + (if markread (setq tags (delete "unread" tags))) + (notmuch-search-set-tags tags)) + (forward-line) + +(defun notmuch-show-archive-thread-maybe-mark-read (markread shownext) (save-excursion (goto-char (point-min)) (while (not (eobp)) @@ -194,15 +221,9 @@ Unlike builtin `next-line' this version accepts no arguments." (forward-char)) (if (not (re-search-forward notmuch-show-message-begin-regexp nil t)) (goto-char (point-max) - (let ((parent-buffer notmuch-show-parent-buffer)) -(kill-this-buffer) -(if parent-buffer - (progn - (switch-to-buffer parent-buffer) - (forward-line) - (notmuch-search-show-thread) + (if shownext (notmuch-show-next-thread markread) (notmuch-kill-message-buffer markread))) -(defun notmuch-show-mark-read-then-archive-thread () +(defun notmuch-show-mark-read-archive-thread-next-thread () "Remove \"unread\" tag from each message, then archive and show next thread. Archive each message currrently shown by removing the \"unread\" @@ -215,9 +236,22 @@ being delivered to the same thread. It does not archive the entire thread, but only the messages shown in the current buffer." (interactive) - (notmuch-show-archive-thread-maybe-mark-read t)) + (notmuch-show-archive-thread-maybe-mark-read t t)) + +(defun notmuch-show-mark-read-archive-thread-kill-buffer () + "Remove \"unread\" tag from each message, then archive and kill the buffer. + +Archive each message currrently shown by removing the \"unread\" +and \"inbox\" tag from each. Then kill this buffer. + +Note: This command is safe from any race condition of new messages +being delivered to the same thread. It does not archive the +entire thread, but only the messages shown in the current +buffer." + (interactive) + (notmuch-show-archive-thread-maybe-mark-read t nil)) -(defun notmuch-show-archive-thread () +(defun notmuch-show-archive-thread-next-thread () "Archive each message in thread, and show next thread from search. Archive each message currrently shown by removing the \"inbox\" @@ -229,7 +
[notmuch] Working with Maildir storage?
On Tue, 17 Nov 2009 15:33:01 -0500, Lars Kellogg-Stedman wrote: > > See the patch just posted here. I've also pushed a slightly more complicated (and complete) fix to my private notmuch repository git://keithp.com/git/notmuch > Is the list archived anywhere? Oops. Looks like Carl's mail server is broken. He's traveling to Barcelona today and so it won't get fixed for a while. Thanks to everyone for trying out notmuch! -keith
[notmuch] [PATCH 1/2] Close message file after parsing message headers
On Tue, 17 Nov 2009 09:13:27 -0800, Carl Worth wrote: > I didn't apply Keith's fix yet, because I think I'd rather just fix the > indexer to store the In-Reply-To header in a separate term prefix from > the term used for the References header[*]. That will then let us lookup > the in-reply-to value later for thread constructions without having to > open the original email file at all. Threading the message also involves displaying the from and to contents, which requires opening the message file. The alternative to the fix I provided is to just parse all of the message headers when first opening the message; it could then be immediately closed and the hash referred to for all header data. Given the choice, just having the caller say when it has finished with a message is probably a reasonable option... -keith
[notmuch] preliminary FreeBSD support
On Tue, 17 Nov 2009 11:36:14 -0800, Alex Botero-Lowry wrote: > I saw the announcement this morning, and was very excited, as I had been > hoping sup would be turned into a library, > since I like the concept more than the UI (I'd rather an emacs interface). Hi Alex, That's great! It's good to hear that there are like-minded people out there. I hope that Notmuch will be useful for you. > I did a preliminary compile which worked out fine, but > sysconf(_SC_SC_GETPW_R_SIZE_MAX) returns -1 on > FreeBSD, so notmuch_config_open segfaulted. > > Attached is a patch that supplies a default buffer size of 64 in cases where > -1 is returned. Thanks for the patch. As we discussed in IRC[*], we should probably do the correct thing and check for ERANGE and loop as necessary (even if sysconf returns a positive value). Example code here: http://www.opengroup.org/austin/docs/austin_328.txt -Carl [*] #notmuch on irc.freenode.net for those who didn't just guess that already, (and I'll add that to the website soon).
[notmuch] preliminary FreeBSD support
I saw the announcement this morning, and was very excited, as I had been hoping sup would be turned into a library, since I like the concept more than the UI (I'd rather an emacs interface). I did a preliminary compile which worked out fine, but sysconf(_SC_SC_GETPW_R_SIZE_MAX) returns -1 on FreeBSD, so notmuch_config_open segfaulted. Attached is a patch that supplies a default buffer size of 64 in cases where -1 is returned. http://www.opengroup.org/austin/docs/austin_328.txt - seems to indicate this is acceptable behavior, and http://mail-index.netbsd.org/pkgsrc-bugs/2006/06/07/msg016808.htmlspecifically uses 64 as the buffer size. -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/380386ea/attachment.htm> -- next part -- A non-text attachment was scrubbed... Name: 0001-Deal-with-situation-where-sysconf-_SC_GETPW_R_SIZE_M.patch Type: application/octet-stream Size: 1050 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091117/380386ea/attachment.obj>
[notmuch] [PATCH 1/2] Close message file after parsing message headers
On Tue, 17 Nov 2009 21:28:37 +0600, Mikhail Gusarov wrote: > Keeping unused files open helps to see "Too many open files" often. > > Signed-off-by: Mikhail Gusarov ... On Tue, 17 Nov 2009 21:28:38 +0600, Mikhail Gusarov wrote: > > Signed-off-by: Mikhail Gusarov > --- > lib/message.cc |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) Hi Mikhail, Welcome to notmuch, and thanks for these patches! I've pushed both of them out now. Keith ran into the same problem of "too many open files" and wrote a more complex fix, (which included what you did here). His code can be seen at: git://keithp.com/git/notmuch I didn't apply Keith's fix yet, because I think I'd rather just fix the indexer to store the In-Reply-To header in a separate term prefix from the term used for the References header[*]. That will then let us lookup the in-reply-to value later for thread constructions without having to open the original email file at all. -Carl [*] Yes, this is my first post to our new mailing list and I'm already spouting off about "terms" and "prefixes" without any definitions. I apologize for that. I hope that people will ask questions freely here on the list whenever anything is not clear, and I'll be glad to explain things as needed. (Then when can shove answers into a HACKING document.) PS. This reply is a great example of a feature that notmuch *almost* supports already---repling to multiple messages at once. The "notmuch reply" command line does everything necessary to make this work, but we haven't yet hooked up any keybindings for this in the emacs client yet. Obviously, 'r' from the search view could reply to the entire thread. But when viewing a thread, anyone have a good keybinding suggestion? (There's obviously 'R' as opposed to 'r', but I think we'll probably want to distinguish "reply to sender" from "reply to all" before trying to distinguish "reply to message" from "reply to thread" (which I imagine is more rare of an operation).
