[notmuch] [PATCH 2/2] .gitignore: Add common editor droppings
--- .gitignore |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index d277c5a..a210779 100644 --- a/.gitignore +++ b/.gitignore @@ -2,4 +2,6 @@ notmuch notmuch.1.gz *.[ao] +*~ +.*.swp -- 1.6.5.2.433.g23cdb
[notmuch] [PATCH 1/2] zsh: Initial zsh-completion for notmuch
Signed-off-by: Ingmar Vanhassel --- _notmuch | 74 ++ 1 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 _notmuch diff --git a/_notmuch b/_notmuch new file mode 100644 index 000..00c9248 --- /dev/null +++ b/_notmuch @@ -0,0 +1,74 @@ +#compdef notmuch + +# ZSH completion for `notmuch` +# Copyright 2009 Ingmar Vanhassel + +_notmuch_commands() +{ + local -a notmuch_commands + notmuch_commands=( +'setup:interactively set up notmuch for first use' +'new:find and import any new message to the database' +'search:search for messages matching the search terms, display matching threads as results' +'reply:constructs a reply template for a set of messages' +'show:show all messages matching the search terms' +'tag:add or remove tags for all messages matching the search terms' +'dump:creates a plain-text dump of the tags of each message' +'restore:restores the tags from the given file' +'help:show details on a command' + ) + + _describe -t command 'command' notmuch_commands +} + +_notmuch_dump() +{ + _files +} + +_notmuch_help_topics() +{ + local -a notmuch_help_topics + notmuch_help_topics=( +'search-terms:show common search-terms syntax' + ) + _describe -t notmuch-help-topics 'topic' notmuch_help_topics +} + +_notmuch_help() +{ + _alternative \ +_notmuch_commands \ +_notmuch_help_topics +} + +_notmuch_restore() +{ + _files +} + +_notmuch_search() +{ + _arguments -s : \ +'--max-threads=[display only the first x threads from the search results]:number of threads to show: ' \ +'--first=[omit the first x threads from the search results]:number of threads to omit: ' \ +'--sort=[sort results]:sorting:((newest-first\:"reverse chronological order" oldest-first\:"chronological order"))' +} + +_notmuch() +{ + if (( CURRENT > 2 )) ; then +local cmd=${words[2]} +curcontext="${curcontext%:*:*}:notmuch-$cmd" +(( CURRENT-- )) +shift words +_call_function ret _notmuch_$cmd +return ret + else +_notmuch_commands + fi +} + +_notmuch "$@" + +# vim: set sw=2 sts=2 ts=2 et ft=zsh : -- 1.6.5.2.433.g23cdb
[notmuch] Mac OS X/Darwin compatibility issues
On Wed, 18 Nov 2009 11:50:17 +0800, Jjgod Jiang wrote: > 1. g++ reports 'warning: command line option "-Wmissing-declarations" > is valid for C/ObjC but not for C++' In cairo, what we do is have a huge list of desired warnings and then test each one in turn with a test-compile in the configure script. That's probably what we should do here, (I recently established a Makefile.config for this purpose that should be generated by the configure script.) > 2. > notmuch-reply.c: In function ?address_is_users?: > notmuch-reply.c:87: warning: passing argument 2 of > ?notmuch_config_get_user_other_email? from incompatible pointer type Thanks for the report. I think I saw a fix for this in a commit from Chris Wilson that's in my queue. (Though from a quick glance I'm not sure where the size_t type got started in the code and propagated throught this part). > 3. Several errors about missing GNU extensions like getline() and strndup(): > > warning: implicit declaration of function ?getline? > error: ?strndup? was not declared in this scope > > We can implement these with fgets() and strncpy() though. Yes. I knew I was "cheating" by using some GNU extensions here. I'm happy to accept portability patches for these things, but it's hard for me to get excited about writing them myself. Care to take a whack at these? -Carl
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
>From 24711481dfe770417aa0a13308a9bb842dfb03f4 Mon Sep 17 00:00:00 2001 From: Aneesh Kumar K.V Date: Wed, 18 Nov 2009 21:20:12 +0530 Subject: [PATCH] notmuch: Add Maildir directory name as tag name for messages This patch adds maildir directory name as the tag name for messages. This helps in adding tags using filtering already provided by procmail. Signed-off-by: Aneesh Kumar K.V --- notmuch-new.c | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 5405a9f..50d0a5a 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -96,6 +96,7 @@ add_files_print_progress (add_files_state_t *state) static notmuch_status_t add_files_recursive (notmuch_database_t *notmuch, const char *path, +const char *tag, struct stat *st, add_files_state_t *state) { @@ -186,6 +187,7 @@ add_files_recursive (notmuch_database_t *notmuch, case NOTMUCH_STATUS_SUCCESS: state->added_messages++; tag_inbox_and_unread (message); + notmuch_message_add_tag (message, tag); break; /* Non-fatal issues (go on to next file) */ case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: @@ -223,7 +225,13 @@ add_files_recursive (notmuch_database_t *notmuch, } } } else if (S_ISDIR (st->st_mode)) { - status = add_files_recursive (notmuch, next, st, state); + if ((strcmp (entry->d_name, "cur") == 0) || + (strcmp (entry->d_name, "new") == 0) || + (strcmp (entry->d_name, "tmp") == 0)) { + status = add_files_recursive (notmuch, next, tag, st, state); + } else { + status = add_files_recursive (notmuch, next, entry->d_name, st, state); + } if (status && ret == NOTMUCH_STATUS_SUCCESS) ret = status; } @@ -285,7 +293,7 @@ add_files (notmuch_database_t *notmuch, timerval.it_value.tv_usec = 0; setitimer (ITIMER_REAL, &timerval, NULL); -status = add_files_recursive (notmuch, path, &st, state); +status = add_files_recursive (notmuch, path, basename(path), &st, state); /* Now stop the timer. */ timerval.it_interval.tv_sec = 0; -- 1.6.5.2.74.g610f9
[notmuch] [PATCH] notmuch: Add search mode hook
On Thu, 19 Nov 2009 10:25:37 +0530, "Aneesh Kumar K.V" wrote: > This patch add notmuch-search-mode-hook and rename > notmuch-show-hook to notmuch-show-mode-hook. This > also runs notmuch-show-mode-hook when we enable > notmuch-show-mode I'm not sure we want to run the hooks that early; I can easily imagine hooks that want to be run after the message has been loaded. -- keith.packard at intel.com -- 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/20091118/e3aa9621/attachment.pgp>
[notmuch] [PATCH] Have git ignore tags & cscope files
--- .gitignore |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 8417d60..ef515f2 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,6 @@ TAGS +tags +*cscope* .deps notmuch notmuch.1.gz -- 1.5.4.3
[notmuch] [PATCH] notmuch: Add tag archive when archiving the mails
>From a2325b950016f39290a0c6f0d6aa3417584eb4e8 Mon Sep 17 00:00:00 2001 From: Aneesh Kumar K.V Date: Wed, 18 Nov 2009 20:45:45 +0530 Subject: [PATCH] notmuch: Add tag archive when archiving the mails This enables us to search for archived mails later Signed-off-by: Aneesh Kumar K.V --- notmuch.el |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index 87116f9..ec2155a 100644 --- a/notmuch.el +++ b/notmuch.el @@ -196,6 +196,7 @@ Unlike builtin `next-line' this version accepts no arguments." (if markread (notmuch-show-remove-tag "unread" "inbox") (notmuch-show-remove-tag "inbox")) + (notmuch-show-add-tag "archive") (if (not (eobp)) (forward-char)) (if (not (re-search-forward notmuch-show-message-begin-regexp nil t)) -- 1.6.5.2.74.g610f9
[notmuch] [PATCH] notmuch: Add hooks for show-mode and search-mode
>From e3a801c90ed5e037b68bd16807606388e6dbe6e8 Mon Sep 17 00:00:00 2001 From: Aneesh Kumar K.V Date: Wed, 18 Nov 2009 20:43:13 +0530 Subject: [PATCH] notmuch: Add hooks for show-mode and search-mode This enables to do things like (add-hook 'notmuch-search-mode-hook (lambda() (hl-line-mode 1) )) Signed-off-by: Aneesh Kumar K.V --- notmuch.el | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/notmuch.el b/notmuch.el index 014d15b..87116f9 100644 --- a/notmuch.el +++ b/notmuch.el @@ -57,6 +57,12 @@ "Keymap for \"notmuch show\" buffers.") (fset 'notmuch-show-mode-map notmuch-show-mode-map) +(defvar notmuch-show-mode-hook nil + "Hooks run when notmuch-show-mode is enabled") + +(defvar notmuch-search-mode-hook nil + "Hooks run when notmuch-search-mode is enabled") + (defvar notmuch-show-signature-regexp "\\(-- ?\\|_+\\)$" "Pattern to match a line that separates content from signature. @@ -636,7 +642,8 @@ view, (remove the \"inbox\" tag from each), with (use-local-map notmuch-show-mode-map) (setq major-mode 'notmuch-show-mode mode-name "notmuch-show") - (setq buffer-read-only t)) + (setq buffer-read-only t) + (run-hooks 'notmuch-show-mode-hook)) (defun notmuch-show (thread-id &optional parent-buffer) "Run \"notmuch show\" with the given thread ID and display results. @@ -759,7 +766,8 @@ global search. (use-local-map notmuch-search-mode-map) (setq major-mode 'notmuch-search-mode mode-name "notmuch-search") - (setq buffer-read-only t)) + (setq buffer-read-only t) + (run-hooks 'notmuch-search-mode-hook)) (defun notmuch-search-find-thread-id () (save-excursion -- 1.6.5.2.74.g610f9
[notmuch] How to list archived mails
Hi, Once i mark the mail as archived how do i search for them ? Right now with notmuch.el i am adding a tag "archive" when i am archiving the mail. I am just wondering is this the right way ? -aneesh
[notmuch] [PATCH] Handle rename of message file
On Thu, 19 Nov 2009 08:11:12 +0600, Mikhail Gusarov wrote: > > Twas brillig at 18:06:09 18.11.2009 UTC-08 when keithp at keithp.com did gyre > and gimble: > > KP> Checking for new files is easy; notmuch already does that, and so > KP> handling renames doesn't seem all that difficult. > > Except rename does not change mtime of file, and so it won't be picked > up by 'notmuch new'. Yeah, good point -- notmuch new doesn't make sure each file it finds is already in the database. Again, some kind of inotify-based daemon would make that efficient, while starting up that daemon could take some time while the database was searched for new or missing files. Alternatively, we could record the contents of the directory after scanning it and then use that to track file changes. It seems like the current database just doesn't have enough information to make this tractable. -- keith.packard at intel.com -- 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/20091118/693379c8/attachment-0001.pgp>
[notmuch] [PATCH] Handle rename of message file
On Thu, 19 Nov 2009 02:08:15 +0100, Carl Worth wrote: > I'd love to hear more from you on any experiments/ideas you have in this > area. It would be a really nice feature to have, (particularly for > people who are experimenting with notmuch while still using some other > primary email program that keeps fiddling with the filenames). Checking for new files is easy; notmuch already does that, and so handling renames doesn't seem all that difficult. The hard part to me is detecting deleted messages; about the only thing I can imagine being at all efficient is to use inotify in a daemon. Starting that daemon up would entail scanning the database for all messages in a particular directory and then looking for those files to see if they were still around. Ick. -- keith.packard at intel.com -- 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/20091118/3e449797/attachment.pgp>
[notmuch] Introducing myself
On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote: > So I'd written a bunch of functional code, only to find myself stuck at > the very last step, (hooking it up to the existing sup interface). Then > Keith suggested emacs and it all seemed pretty easy since I'd already > done all the Xapian work. So it's funny, I was only willing to commit to > this project because I wasn't consciously aware I was working on it. > Otherwise it would have seemed to overwhelming to start. :-) I tried the "notmuch.el" Emacs mode, and have just installed Emacs in order to be able to try it out. As I have been using Vim for the last ~9 years, probably that was the reason why I found it not very comfortable. Even so, I am able of searching, sending and tagging mail quite happily. Apart from it being a bit Spartan, the only issue I have found so far is that I keep pushing the Escape key a lot -- which is my fault as that is a compulsive behaviour derived of using a Vi-like editor :D (Side note: I would not like to start an editor-religion debate, I just want you to know that most probably it is my fault when I say that I am not very comfortable with the Emacs mode) I showed the thing to my work mates this morning and most of them said that they would like to have Mutt-like keybindings *with* Not Much's search and tagging running behind it. I also think it would be great to have a curses-based UI, so this may be a good opportunity to start doing some serious coding with it in my spare time. > > Also, I would like to share one idea [...] adding a "X-Tags" header > > field or by reusing the "Keywords" one. This way, the index could > > be totally recreated by re-reading the mail directories, and this > > would also allow to a tools like OfflineIMAP [1] to get the mails into a > > local maildir, tagging and indexing the mails with the e-mail reader and > > then syncing back the messages with the "X-Tags" header to the IMAP server. > > This would allow to use the mail reader from a different computer and still > > have everything tagged finely. > > It is an interesting idea. But there's also something really comforting > about the email indexed never modifying the mail files. If you're > reading the notmuch commit logs closely you'll see that I'm not actually > careful enough to be trusted with your mail (but I try). So I like that > I don't even have to trust myself---the worst that happens is that I > have to recreate my index. I already made a comment about this in another reply, I could make the modifications e.g. from a script, so no need to add this in Not Much. Moreover, I agree that if one of the goals is to never modify mailboxes, then the current behaviour is just perfect. > And as Keith mentioned, we've got the "notmuch dump; notmuch restore" > idea working exactly as it did in sup. (Though I am thinking of also > adding thread IDs to that now---more on that later.) > > The big annoyance I had with sup index creation, (I ended up having to > do it more than once too), was that it takes *forever*. Right now, > notmuch is a little bit faster, but not a lot faster. And I've got some > ideas to fix that. It would be really nice if index creation were pain > free. (And maybe it is for some user with small amounts of mail---oh, to > have only 4 messages to have to index!). Wow, that is a lot of mail. Definitely people having as much mail as you (er... I mean "_not much_ mail as you") would benefit from faster indexing. > [*] The problem here is that sup puts serialized ruby data structures > into the data field of its Xapian documents. So being compatible with > sup means being able to recreate serialized data structures for a > particular version of ruby. Scary... -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/db88b07f/attachment.pgp>
[notmuch] Introducing myself
On Tue, 17 Nov 2009 18:03:17 -0800, Keith wrote: > On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro igalia.com> wrote: > > > 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'. I already knew about "dump" and "restore", just wanted to share my (wild) thought. I have been thinking a bit more, and if I understand correctly the philosophy of Not Much is that it will only read my mail and that it will never write to my mailboxes. So my idea makes no sense. The nice thing is that I could make a script to read the index (or the output of "notmuch dump") to add the "X-Tags" headers and mark mail :P Taking into account this and the "do one thing well" motto: there is no point in adding that to Not Much :) Regards, -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/e0ada2f2/attachment.pgp>
[notmuch] [PATCH] Checkin some command-only tcsh completions
--- notmuch-completion.tcsh |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 notmuch-completion.tcsh diff --git a/notmuch-completion.tcsh b/notmuch-completion.tcsh new file mode 100644 index 000..c0d3a44 --- /dev/null +++ b/notmuch-completion.tcsh @@ -0,0 +1,2 @@ +set NOTMUCH_CMD=`notmuch help | awk '/\t/' | cut -f2 |grep -v '^$'` +complete notmuch 'p/1/$NOTMUCH_CMD/' -- 1.6.5.2
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Thu, 19 Nov 2009 01:25:34 +0100, Carl Worth wrote: > On Wed, 18 Nov 2009 09:45:01 -0800, Keith Packard > wrote: > > On Wed, 18 Nov 2009 02:19:26 -0800, Carl Worth wrote: > > You can use kill-buffer directly (C-X k); adding a new special binding > > for that command seems unnecessary to me. > > Well, that's "Control, X, K, Enter", so quite a bit harder than just > 'x'. :-) I'd forgotten about the 'q' binding, which used to be the same as 'x' and is now different. Similar to how fdisk differentiates between 'q'uit without saving changes and 'w'rite table to disk and exit. > But fine, I could move my convenience for "kill buffer" to just 'k'. You've got 'q' already :-) > I think I'd like to see a better mapping for "archive and kill buffer" > to a key other than 'x'. Any ideas? I'm up for almost anything; but I'd have to retrain my fingers to use it instead of 'x' :-) > 1. Before I go into "read a bunch of messages with spacebar" mode I >first arrange for filtered search results that I know I want to read >all together. I generally do the same, but don't read mail in time sequence. One of the reasons I like the threaded reading mode is that I don't *have* to read mail in time sequence as I can review a thread and see the time ordering of the messages within that. > 2. When I archive a thread with 'a', I'm not necessarily always planning >to read the next message (just because notmuch is presenting it to >me). And if not, I'll just press 'x' right away. Right, if you use the 'a' key to flip to a new message, you probably don't want to use 'x' on the final (and still essentially ignored) message. >Of course, for this I need an "archive all" binding that >doesn't exist yet. And I also really need to fix the Xapian bug so >that archiving 100 threads doesn't take *forever* like it does >currently. yes, please! I'd even be willing to wait at this point... -- keith.packard at intel.com -- 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/20091118/46d9c4b0/attachment.pgp>
[notmuch] Mac OS X/Darwin compatibility issues
On Thu, 19 Nov 2009 10:45:28 +1100, Stewart Smith wrote: > On Wed, Nov 18, 2009 at 11:27:20PM +0100, Carl Worth wrote: > > Yes. I knew I was "cheating" by using some GNU extensions here. I'm > > happy to accept portability patches for these things, but it's hard for > > me to get excited about writing them myself. > > > > Care to take a whack at these? > > http://www.gnu.org/software/gnulib/ > > could be a partial answer. > Why add yet another dependency for a couple of functions? Especially considering how notmuch already depends on glib which includes portability functions for various things. alex
[notmuch] Why is no. of files from count_files reset to 0?
Hello, The function count_file returns the total number of files to be processed, the result is then stored in add_files_state.total_files. But that variable is reset back to 0 in notmuch_new_command. When I comment out the following line (before add_files is called): add_files_state.total_files = 0; The progress indicator shows the total number of files to be processed, as well as the time remaining. This is, IMHO, much better, especially if you process a large collection of emails. Is there any reason for having the variable reset to 0 before calling add_files? Thanks! -- Jan
[notmuch] [PATCH] Fix a compile warning under gcc-4.4.1
--- Hello, This fixes the following for me: notmuch-reply.c: In function ???address_is_users???: notmuch-reply.c:87: warning: passing argument 2 of ???notmuch_config_get_user_other_email??? from incompatible pointer type notmuch-client.h:174: note: expected ???size_t *??? but argument is of type ???unsigned int *??? notmuch-reply.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 4a4a782..344b6e3 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -78,7 +78,7 @@ address_is_users (const char *address, notmuch_config_t *config) { const char *primary; char **other; -unsigned int i, other_len; +size_t i, other_len; primary = notmuch_config_get_user_primary_email (config); if (strcmp (primary, address) == 0) -- 1.6.2.5
[notmuch] Mac OS X/Darwin compatibility issues
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]. - Jiang [1] http://stackoverflow.com/questions/1117108/compiling-c-code-using-gnu-c-getline-on-mac-osx
[notmuch] [PATCH] notmuch: Add tag archive when archiving the mails
On Wed, Nov 18, 2009 at 1:07 PM, Keith Packard wrote: > >> This enables us to search for archived mails later > > I think you can just use 'not tag:inbox' as 'archived' really just means > 'doesn't have the inbox tag'. That resulted in an error for me: $ notmuch search not tag:inbox A Xapian exception occurred: Syntax: NOT A Xapian exception occurred: Syntax: NOT -- Jeff Ollie
[notmuch] [PATCH] Make reply/show/tag all require at least one search term
In particular, notmuch tag -inbox "" tended to take a long time to run, happened if you hit 'a' on a blank line in the search view and probably didn't have the desired effect. Signed-off-by: Keith Packard --- notmuch-reply.c | 13 + notmuch-show.c | 13 + notmuch-tag.c |8 3 files changed, 22 insertions(+), 12 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 4a4a782..31e2c87 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -196,16 +196,21 @@ notmuch_reply_command (void *ctx, int argc, char *argv[]) if (config == NULL) return 1; -notmuch = notmuch_database_open (notmuch_config_get_database_path (config)); -if (notmuch == NULL) - return 1; - query_string = query_string_from_args (ctx, argc, argv); if (query_string == NULL) { fprintf (stderr, "Out of memory\n"); return 1; } +if (*query_string == '\0') { + fprintf (stderr, "Error: notmuch reply requires at least one search term.\n"); + return 1; +} + +notmuch = notmuch_database_open (notmuch_config_get_database_path (config)); +if (notmuch == NULL) + return 1; + query = notmuch_query_create (notmuch, query_string); if (query == NULL) { fprintf (stderr, "Out of memory\n"); diff --git a/notmuch-show.c b/notmuch-show.c index 59a58c2..c0c3ca3 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -196,16 +196,21 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) if (config == NULL) return 1; -notmuch = notmuch_database_open (notmuch_config_get_database_path (config)); -if (notmuch == NULL) - return 1; - query_string = query_string_from_args (ctx, argc, argv); if (query_string == NULL) { fprintf (stderr, "Out of memory\n"); return 1; } +if (*query_string == '\0') { + fprintf (stderr, "Error: notmuch show requires at least one search term.\n"); + return 1; +} + +notmuch = notmuch_database_open (notmuch_config_get_database_path (config)); +if (notmuch == NULL) + return 1; + query = notmuch_query_create (notmuch, query_string); if (query == NULL) { fprintf (stderr, "Out of memory\n"); diff --git a/notmuch-tag.c b/notmuch-tag.c index 7d92ec4..12ab86c 100644 --- a/notmuch-tag.c +++ b/notmuch-tag.c @@ -83,8 +83,10 @@ notmuch_tag_command (void *ctx, unused (int argc), unused (char *argv[])) return 1; } -if (i == argc) { - fprintf (stderr, "Error: 'notmuch tag' requires at least one search term.\n"); +query_string = query_string_from_args (ctx, argc - i, &argv[i]); + +if (*query_string == '\0') { + fprintf (stderr, "Error: notmuch tag requires at least one search term.\n"); return 1; } @@ -96,8 +98,6 @@ notmuch_tag_command (void *ctx, unused (int argc), unused (char *argv[])) if (notmuch == NULL) return 1; -query_string = query_string_from_args (ctx, argc - i, &argv[i]); - query = notmuch_query_create (notmuch, query_string); if (query == NULL) { fprintf (stderr, "Out of memory.\n"); -- 1.6.5.2
[notmuch] [PATCH] count_files: sort directory in inode order before statting
--- notmuch-new.c | 30 ++ 1 files changed, 10 insertions(+), 20 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 11fad8c..c5f841a 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -308,36 +308,26 @@ add_files (notmuch_database_t *notmuch, static void count_files (const char *path, int *count) { -DIR *dir; -struct dirent *e, *entry = NULL; -int entry_length; -int err; +struct dirent *entry = NULL; char *next; struct stat st; +struct dirent **namelist = NULL; -dir = opendir (path); +int n_entries= scandir(path, &namelist, 0, ino_cmp); -if (dir == NULL) { +if (n_entries == -1) { fprintf (stderr, "Warning: failed to open directory %s: %s\n", path, strerror (errno)); goto DONE; } -entry_length = offsetof (struct dirent, d_name) + - pathconf (path, _PC_NAME_MAX) + 1; -entry = malloc (entry_length); +int i=0; while (!interrupted) { - err = readdir_r (dir, entry, &e); - if (err) { - fprintf (stderr, "Error reading directory: %s\n", -strerror (errno)); - free (entry); - goto DONE; - } +if (i == n_entries) +break; - if (e == NULL) - break; +entry= namelist[i++]; /* Ignore special directories to avoid infinite recursion. * Also ignore the .notmuch directory. @@ -376,8 +366,8 @@ count_files (const char *path, int *count) DONE: if (entry) free (entry); - -closedir (dir); +if (namelist) +free (namelist); } int -- 1.6.3.3
[notmuch] [PATCH 2/2] Read mail directory in inode number order
This gives a rather decent reduction in number of seeks required when reading a Maildir that isn't in pagecache. Most filesystems give some locality on disk based on inode numbers. In ext[234] this is the inode tables, in XFS groups of sequential inode numbers are together on disk and the most significant bits indicate allocation group (i.e inode 1,000,000 is always after inode 1,000). With this patch, we read in the whole directory, sort by inode number before stat()ing the contents. Ideally, directory is sequential and then we make one scan through the file system stat()ing. Since the universe is not ideal, we'll probably seek during reading the directory and a fair bit while reading the inodes themselves. However... with readahead, and stat()ing in inode order, we should be in the best place possible to hit the cache. In a (not very good) benchmark of "how long does it take to find the first 15,000 messages in my Maildir after 'echo 3 > /proc/sys/vm/drop_caches'", this patch consistently cut at least 8 seconds off the scan time. Without patch: 50 seconds With patch: 38-42 seconds. (I did this in a previous maildir reading project and saw large improvements too) --- notmuch-new.c | 32 +++- 1 files changed, 15 insertions(+), 17 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 83a05ba..11fad8c 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -73,6 +73,11 @@ add_files_print_progress (add_files_state_t *state) fflush (stdout); } +static int ino_cmp(const struct dirent **a, const struct dirent **b) +{ + return ((*a)->d_ino < (*b)->d_ino)? -1: 1; +} + /* Examine 'path' recursively as follows: * * o Ask the filesystem for the mtime of 'path' (path_mtime) @@ -100,13 +105,12 @@ add_files_recursive (notmuch_database_t *notmuch, add_files_state_t *state) { DIR *dir = NULL; -struct dirent *e, *entry = NULL; -int entry_length; -int err; +struct dirent *entry = NULL; char *next = NULL; time_t path_mtime, path_dbtime; notmuch_status_t status, ret = NOTMUCH_STATUS_SUCCESS; notmuch_message_t *message = NULL; +struct dirent **namelist = NULL; /* If we're told to, we bail out on encountering a read-only * directory, (with this being a clear clue from the user to @@ -122,31 +126,23 @@ add_files_recursive (notmuch_database_t *notmuch, path_mtime = st->st_mtime; path_dbtime = notmuch_database_get_timestamp (notmuch, path); +int n_entries= scandir(path, &namelist, 0, ino_cmp); -dir = opendir (path); -if (dir == NULL) { +if (n_entries == -1) { fprintf (stderr, "Error opening directory %s: %s\n", path, strerror (errno)); ret = NOTMUCH_STATUS_FILE_ERROR; goto DONE; } -entry_length = offsetof (struct dirent, d_name) + - pathconf (path, _PC_NAME_MAX) + 1; -entry = malloc (entry_length); +int i=0; while (!interrupted) { - err = readdir_r (dir, entry, &e); - if (err) { - fprintf (stderr, "Error reading directory: %s\n", -strerror (errno)); - ret = NOTMUCH_STATUS_FILE_ERROR; - goto DONE; - } - - if (e == NULL) + if (i == n_entries) break; +entry= namelist[i++]; + /* If this directory hasn't been modified since the last * add_files, then we only need to look further for * sub-directories. */ @@ -243,6 +239,8 @@ add_files_recursive (notmuch_database_t *notmuch, free (entry); if (dir) closedir (dir); +if (namelist) + free (namelist); return ret; } -- 1.6.3.3
[notmuch] Problem Building on OSX leopard 10.5.8
Hello, Having given up on most email clients yet trapped by them, I came across notmuch. Quite eager to build, 1.download xapian, A suggestion : In the INSTALL/README file, mention that xapian-config should be on path and that it be called xapian-config. When I installed the latest, it was installed in /usr/local/bin (not in my path) at xapian-config-1.1 2. download gmime (no problem here) 3. Install talloc (the makefile has errors in it) Problem Building notmuch: I got this error: lib/index.cc: In function ?void _index_address_mailbox(notmuch_message_t*, const char*, InternetAddress*)?: lib/index.cc:46: error: ?strndup? was not declared in this scope Any ideas? Thank you Saptarshi
[notmuch] [PATCH] notmuch build: add a RPM spec file
Add a spec file for building RPM packages. Signed-off-by: Jeffrey C. Ollie --- notmuch.spec | 110 ++ 1 files changed, 110 insertions(+), 0 deletions(-) create mode 100644 notmuch.spec diff --git a/notmuch.spec b/notmuch.spec new file mode 100644 index 000..cca3a1b --- /dev/null +++ b/notmuch.spec @@ -0,0 +1,110 @@ +%global git 306635c2 + +%if %($(pkg-config emacs) ; echo $?) +%global emacs_version 23.1 +%global emacs_lispdir %{_datadir}/emacs/site-lisp +%global emacs_startdir %{_datadir}/emacs/site-lisp/site-start.d +%else +%global emacs_version %(pkg-config emacs --modversion) +%global emacs_lispdir %(pkg-config emacs --variable sitepkglispdir) +%global emacs_startdir %(pkg-config emacs --variable sitestartdir) +%endif + +Name: notmuch +Version:0.0 +Release:0.3.%{git}%{?dist} +Summary:Not much of an email program + +Group: Applications/Internet +License:GPLv3+ +URL:http://notmuchmail.org/ + +# +# To create a tarball: +# +# git clone git://notmuchmail.org/git/notmuch +# cd notmuch +# git archive --format=tar --prefix=notmuch/ HEAD | bzip2 > notmuch-`git show-ref --hash=8 HEAD`.tar.bz2 +# +Source0:notmuch-%{git}.tar.bz2 +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) + +BuildRequires: xapian-core-devel +BuildRequires: gmime-devel +BuildRequires: libtalloc-devel +BuildRequires: zlib-devel +BuildRequires: emacs-el +BuildRequires: emacs-nox + +Requires: emacs(bin) >= %{emacs_version} + +%description +* "Not much mail" is what Notmuch thinks about your email + collection. Even if you receive 12000 messages per month or have on + the order of millions of messages that you've been saving for + decades. Regardless, Notmuch will be able to quickly search all of + it. It's just plain not much mail. + +* "Not much mail" is also what you should have in your inbox at any + time. Notmuch gives you what you need, (tags and fast search), so + that you can keep your inbox tamed and focus on what really matters + in your life, (which is surely not email). + +* Notmuch is an answer to Sup. Sup is a very good email program + written by William Morgan (and others) and is the direct inspiration + for Notmuch. Notmuch began as an effort to rewrite + performance-critical pieces of Sup in C rather than ruby. From + there, it grew into a separate project. One significant contribution + Notmuch makes compared to Sup is the separation of the + indexer/searcher from the user interface. (Notmuch provides a + library interface so that its indexing/searching/tagging features + can be integrated into any email program.) + +* Notmuch is not much of an email program. It doesn't receive messages + (no POP or IMAP suport). It doesn't send messages (no mail composer, + no network code at all). And for what it does do (email search) that + work is provided by an external library, Xapian. So if Notmuch + provides no user interface and Xapian does all the heavy lifting, + then what's left here? Not much. + +Notmuch is still in the early stages of development, but it does +include one user interface, (implemented within emacs), which has at +least two users using it for reading all of their incoming mail. If +you've been looking for a fast, global-search and tag-based email +reader to use within emacs, then Notmuch may be exactly what you've +been looking for. + +Otherwise, if you're a developer of an existing email program and +would love a good library interface for fast, global search with +support for arbitrary tags, then Notmuch also may be exactly what +you've been looking for. + +%prep +%setup -q -n notmuch + +%build +make %{?_smp_mflags} CFLAGS="%{optflags}" +emacs -batch -f batch-byte-compile notmuch.el + +%install +rm -rf %{buildroot} +make install DESTDIR=%{buildroot} prefix=%{_prefix} +mkdir -p %{buildroot}%{emacs_startdir} +install -m0644 -p notmuch.el* %{buildroot}%{emacs_startdir} + +%clean +rm -rf %{buildroot} + +%files +%defattr(-,root,root,-) +%doc AUTHORS COPYING COPYING-GPL-3 INSTALL README TODO + +%{_sysconfdir}/bash_completion.d/notmuch +%{_bindir}/notmuch +%{_mandir}/man1/notmuch.1* +%{emacs_startdir}/notmuch.el* + +%changelog +* Wed Nov 18 2009 Jeffrey C. Ollie - 0.0-0.3.306635c2 +- First version + -- 1.6.5.2
[notmuch] RPM spec file
I prefere managing all of the software on my system with RPM, so I came up with a quick spec file for building RPMS. Once notmuch settles down and I continue using it I may submit notmuch to Fedora as an official package. If you'd like your own RPMS build your own, I don't plan on offering a repository of binary packages.
[notmuch] [PATCH] notmuch: Add tag archive when archiving the mails
On Wed, 18 Nov 2009 13:50:58 -0600, Jeffrey Ollie wrote: > That resulted in an error for me: > > $ notmuch search not tag:inbox > A Xapian exception occurred: Syntax: NOT > A Xapian exception occurred: Syntax: NOT Yeah, NOT isn't a unary operator in xapian; it's a binary operator that means 'AND NOT'. The Xapian docs say that if you set the FLAG_PURE_NOT flag, you'll get the unary behaviour, but I haven't tried that. -- keith.packard at intel.com -- 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/20091118/a43dfab8/attachment.pgp>
[notmuch] [PATCH] Fix linking with gcc to use g++ to link in C++ libs.
Previously, Ubuntu 9.10, gcc 4.4.1 was getting: ccache gcc `pkg-config --libs glib-2.0 gmime-2.4 talloc` `xapian-config --libs` notmuch.o notmuch-config.o notmuch-dump.o notmuch-new.o notmuch-reply.o notmuch-restore.o notmuch-search.o notmuch-setup.o notmuch-show.o notmuch-tag.o notmuch-time.o gmime-filter-reply.o query-string.o show-message.o lib/notmuch.a -o notmuch /usr/bin/ld: lib/notmuch.a(database.o): in function global constructors keyed to BOOLEAN_PREFIX_INTERNAL:database.cc(.text+0x3a): error: undefined reference to 'std::ios_base::Init::Init()' --- Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index f824bed..dbd3e20 100644 --- a/Makefile.local +++ b/Makefile.local @@ -18,7 +18,7 @@ notmuch_client_srcs = \ notmuch_client_modules = $(notmuch_client_srcs:.c=.o) notmuch: $(notmuch_client_modules) lib/notmuch.a - $(CC) $(LDFLAGS) $^ -o $@ + $(CXX) $(LDFLAGS) $^ -o $@ notmuch.1.gz: gzip --stdout notmuch.1 > notmuch.1.gz -- 1.6.3.3
[notmuch] Segfault searching for tags
Getting the following segfault with 306635c2 on Fedora 12. Seems to be happening with any 'tag:' search that returns results. For example, 'notmuch search tag:inbox' and 'notmuch search tag:unread' segfault but 'notmuch search tag:nosuchtag', 'notmuch search subject:logwatch' and 'notmuch search video' seem to work fine. Core was generated by `/usr/bin/notmuch search --sort=oldest-first tag:inbox'. Program terminated with signal 11, Segmentation fault. \#0 Xapian::TermIterator::operator* (this=) at api/omtermlistiterator.cc:78 78 RETURN(internal->get_termname()); Current language: auto The current source language is "auto; currently c++". Thread 1 (Thread 15005): \#0 Xapian::TermIterator::operator* (this=) at api/omtermlistiterator.cc:78 No locals. \#1 0x0040d213 in _notmuch_message_get_in_reply_to (message=0x1594f70) at lib/message.cc:288 prefix = 0x415b77 "XREPLYTO" prefix_len = 0 i = {internal = {dest = 0x0}} in_reply_to = "" \#2 0x0040f842 in _resolve_thread_relationships (thread=0x1595a00) at lib/thread.cc:157 node = 0x1596130 message = 0x1594f70 parent = 0x7fff2cade9c8 prev = 0x1595cd0 in_reply_to = \#3 _notmuch_thread_create (thread=0x1595a00) at lib/thread.cc:285 thread = 0x1595a00 thread_id_query = 0x158beb0 matched_query = messages = 0x7fff2cade948 message = thread_id_query_string = matched_query_string = \#4 0x0040f3d0 in notmuch_query_search_threads ( query=, first=, max_threads=) at lib/query.cc:217 threads = 0x158b5f0 thread = 0x6e0077 messages = 0x158b7c0 message = 0x158c580 thread_id = 0x158b890 "2065b08615b4cbbb22d9ee874bb84d3e" seen = 0x15454a0 messages_seen = 0 threads_seen = 0 \#5 0x004089a1 in do_search_threads (ctx=0x1543140, query= 0x7fff2cade8a0, sort=NOTMUCH_SORT_OLDEST_FIRST, first=, max_threads=) at notmuch-search.c:40 thread = threads = 0x1551290 tags = 0x2 date = relative_date = 0x2 \#6 0x00408ddd in notmuch_search_command (ctx=, argc=1, argv=) at notmuch-search.c:156 config = query = 0x158b510 query_str = i = 1 first = max_threads = opt = end = 0x0 sort = \#7 0x0040636f in main (argc=4, argv=0x7fff2cadec98) at notmuch.c:400 local = 0x1543140 command = -- Jeff Ollie
[notmuch] [PATCH] Have git ignore etags file
--- .gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index d277c5a..367caa6 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +TAGS .deps notmuch notmuch.1.gz -- 1.6.5.2
[notmuch] [PATCH] Limit reverse searches to 100 threads.
Yes, this is a lame default, but it serves my purposes. Signed-off-by: Keith Packard --- notmuch.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index 4498200..91ed073 100644 --- a/notmuch.el +++ b/notmuch.el @@ -945,7 +945,7 @@ This function advances point to the next line when finished." (save-excursion (if oldest-first (call-process "notmuch" nil t nil "search" query) - (call-process "notmuch" nil t nil "search" "--reverse" query)) + (call-process "notmuch" nil t nil "search" "--max-threads=100" "--reverse" query)) (notmuch-search-markup-thread-ids) -- 1.6.5.2
[notmuch] [PATCH] Filter out carriage-returns in show and reply output.
Thanks, windows mail clients. Signed-off-by: Keith Packard --- gmime-filter-reply.c |7 --- notmuch-show.c | 21 +++-- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/gmime-filter-reply.c b/gmime-filter-reply.c index 3e298e1..b269db4 100644 --- a/gmime-filter-reply.c +++ b/gmime-filter-reply.c @@ -130,8 +130,9 @@ filter_filter (GMimeFilter *filter, char *inbuf, size_t inlen, size_t prespace, reply->saw_nl = TRUE; else reply->saw_nl = FALSE; - - *outptr++ = *inptr++; + if (*inptr != '\r') + *outptr++ = *inptr; + inptr++; } } else { g_mime_filter_set_size (filter, inlen + 1, FALSE); @@ -150,7 +151,7 @@ filter_filter (GMimeFilter *filter, char *inbuf, size_t inlen, size_t prespace, else *outptr++ = *inptr; reply->saw_angle = FALSE; - } else { + } else if (*inptr != '\r') { if (*inptr == '\n') reply->saw_nl = TRUE; *outptr++ = *inptr; diff --git a/notmuch-show.c b/notmuch-show.c index 7749dbc..4c377e1 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -99,14 +99,23 @@ show_part (GMimeObject *part, int *part_count) if (g_mime_content_type_is_type (content_type, "text", "*") && !g_mime_content_type_is_type (content_type, "text", "html")) { - GMimeStream *stream = g_mime_stream_file_new (stdout); - g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream), FALSE); + GMimeStream *stream_stdout = g_mime_stream_file_new (stdout); + GMimeStream *stream_filter = NULL; + + if (stream_stdout) { + g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE); + stream_filter = g_mime_stream_filter_new(stream_stdout); + g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter), +g_mime_filter_crlf_new(FALSE, FALSE)); + } wrapper = g_mime_part_get_content_object (GMIME_PART (part)); - if (wrapper && stream) - g_mime_data_wrapper_write_to_stream (wrapper, stream); - if (stream) - g_object_unref(stream); + if (wrapper && stream_filter) + g_mime_data_wrapper_write_to_stream (wrapper, stream_filter); + if (stream_filter) + g_object_unref(stream_filter); + if (stream_stdout) + g_object_unref(stream_stdout); } else { -- 1.6.5.2
[notmuch] Mac OS X/Darwin compatibility issues
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++' 2. notmuch-reply.c: In function ?address_is_users?: notmuch-reply.c:87: warning: passing argument 2 of ?notmuch_config_get_user_other_email? from incompatible pointer type That's due to the size incompatibility of 'unsigned int' and 'size_t' (size_t is uint64_t in Mac OS X). 3. Several errors about missing GNU extensions like getline() and strndup(): warning: implicit declaration of function ?getline? error: ?strndup? was not declared in this scope We can implement these with fgets() and strncpy() though. - Jiang
[notmuch] [PATCH 2/2] reply: Pointer mismatch.
Apparently typeof (size_t) != unsigned int on my x86-64. --- notmuch-reply.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 4a4a782..344b6e3 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -78,7 +78,7 @@ address_is_users (const char *address, notmuch_config_t *config) { const char *primary; char **other; -unsigned int i, other_len; +size_t i, other_len; primary = notmuch_config_get_user_primary_email (config); if (strcmp (primary, address) == 0) -- 1.6.5.2
[notmuch] [PATCH 1/2] Makefile: evaluate pkg-config once
Currently the same `pkg-config ...` is executed for every target, so just store the results in a variable. --- Makefile |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 96aaa73..023b2ec 100644 --- a/Makefile +++ b/Makefile @@ -4,15 +4,16 @@ CFLAGS=-O2 # Additional flags that we will append to whatever the user set. # These aren't intended for the user to manipulate. -extra_cflags = `pkg-config --cflags glib-2.0 gmime-2.4 talloc` -extra_cxxflags = `xapian-config --cxxflags` +extra_cflags := $(shell pkg-config --cflags glib-2.0 gmime-2.4 talloc) +extra_cxxflags := $(shell xapian-config --cxxflags) # Now smash together user's values with our extra values override CFLAGS += $(WARN_FLAGS) $(extra_cflags) override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) $(extra_cxxflags) -override LDFLAGS += `pkg-config --libs glib-2.0 gmime-2.4 talloc` \ - `xapian-config --libs` +override LDFLAGS += \ + $(shell pkg-config --libs glib-2.0 gmime-2.4 talloc) \ + $(shell xapian-config --libs) # Include our local Makefile.local first so that its first target is default include Makefile.local -- 1.6.5.2
[notmuch] [PATCH] notmuch: Add tag archive when archiving the mails
> This enables us to search for archived mails later I think you can just use 'not tag:inbox' as 'archived' really just means 'doesn't have the inbox tag'. -- keith.packard at intel.com -- 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/20091118/7fb913e9/attachment.pgp>
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Wed, 18 Nov 2009 02:19:26 -0800, Carl Worth wrote: > I don't like this---but that's because I use 'x' precisely *because* it > preserves these tags. You can use kill-buffer directly (C-X k); adding a new special binding for that command seems unnecessary to me. > Otherwise, you might as well just remove inbox and unread as soon as the > message is presented to the user. And that's a bug in a lot of other > email programs that I'm unwilling to replicate. My mail flow doesn't involve moving directly from one message to the next; I go back to the index after reviewing each one; there isn't a way to mark a buffer as read/archived and *not* view another message -- keith.packard at intel.com -- 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/20091118/15c91b22/attachment.pgp>
[notmuch] [PATCH] We use the message mail system for new mail, let emacs know.
This makes things like the goto-address system bring up the right message composition window. Signed-off-by: Keith Packard --- notmuch.el |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index c95cb43..4498200 100644 --- a/notmuch.el +++ b/notmuch.el @@ -1008,4 +1008,6 @@ current search results AND that are tagged with the given tag." (interactive) (notmuch-search "tag:inbox" t)) +(setq mail-user-agent 'message-user-agent) + (provide 'notmuch) -- 1.6.5.2
[notmuch] request for pull
On Wed, 18 Nov 2009 00:02:56 -0800, Alexander Botero-Lowry wrote: > The following changes since commit e8c9c3e6a534fc6c2919c2c1de63cea7250eb488: > > are available in the git repository at: > > git://alexbl.net/notmuch.git master > > Alexander Botero-Lowry (2): > Error out if no query is supplied to search instead of going into an > infinite loop > set a local truncate-line variable in notmuch-search-mode, so that > subjects don't wrap and make the output look weird Hmm... I used to think pull requests were the best, (and it's true that they still do things better than mail---"git am" and even "git am -3" seem to put git into useless states in some merge-conflict cases). But now that I'm working through this list of patches while I'm on a plane I'm wishing the patches were actually here with me. :-) Well, that's what I have a "todo" tag for. So I'll look at this later when I've got internet access again. (But I believe the first commit is already addressed independently.) BTW, thanks for the patches! -Carl
[notmuch] Link to mailing list archives ?
On Tue, 17 Nov 2009 21:12:23 -0800 (PST), Rolland Santimano wrote: > The link[1] provided on the list page[2] is broken: Hi Rolland, Welcome to the notmuch community. Thanks for the report. This should be fixed now. Do let me know if you run into any further problems. -Carl
[notmuch] [PATCH] Fix linking with gcc to use g++ to link in C++ libs.
On Wed, 18 Nov 2009 12:05:53 +1100, Stewart Smith wrote: > Previously, Ubuntu 9.10, gcc 4.4.1 was getting: Thanks, Stewart! It's always nice to get portability fixes. This should have beeen pushed by the time I will have been able to send this email. :-) -Carl
[notmuch] "notmuch help" outputs to stderr?
On Tue, 17 Nov 2009 20:01:16 -0500, Lars Kellogg-Stedman wrote: > > 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 Thanks Lars! That was obviously a bug, so I really appreciate both your report and your fix. BTW, for future patches, it would be easier for me, (and hopefully not too much harder for you), if you could format your mails so that "git am" will find a good commit message in them. There are a few different ways you can do that: Option (1) takes more work upfront to get comfortable with it and to make sure it works, but it's probably less work (particuarly 1.b with "git send-email) once you get into the flow of it. Option (2) is probably the least different from what you're currently doing. 1. Make a commit locally with the commit message. Then run "git format-patch", (with "git format-patch HEAD~N" where N is the number of commits you want to generate), to generate formatted email messages, (or even an entire mbox). a. Suck those messages up into an email program. Add any commentary (to not be part of the commit message) after the --- separator and send. b. Use "git send-email" to fire the messages off. 2. Just attach the "git diff" output like you did, but then carefully word the subject and body of the email message to look like a commit message. You can again use a --- separator for commentary that's not part of the patch. For example, option (2) would have looked like the below to generate the commit message I ended up using for your commit. Anyway, thanks again, -Carl Subject: [Patch] notmuch help: Print to stdout, not to stderr. Let 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
[notmuch] [PATCH] notmuch new: Support for conversion of spool subdirectories into tags
This patch makes it possible to convert subdirectory names inside the spool directory into message tags. Messages stored in subdirectory "foo" will be marked with tag "foo". Message duplicates found in several subdirectories will be given one tag per subdirectory. This feature can be used to synchronize notmuch's tags with with gmail tags, for example. Gmail IMAP servers convert tags to IMAP subdirectories and those subdirectories can be converted back to tags in notmuch. The patch modifies notmuch_database_add_message function to return a pointer to the message even if a message duplicate was found in the database. This is needed if we want to add a tag for each subdirectory in which a message duplicate was found. In addition to that, it makes the pointer to notmuch_config_t global (previously it was a local variable in notmuch_new_command). The configuration data structure is used by the function which converts subdirectory names to tags. Finally, there is a new function called subdir_to_tag. The function extracts the name of the subdirectory inside the spool from the full path of the message (also removing Maildir's cur,dir,and tmp subdirectories) and adds it as a new tag to the message. Signed-off-by: Jan Janak --- lib/database.cc |3 +- notmuch-new.c | 74 +- 2 files changed, 74 insertions(+), 3 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 3c8d626..f7799d2 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -949,7 +949,8 @@ notmuch_database_add_message (notmuch_database_t *notmuch, DONE: if (message) { - if (ret == NOTMUCH_STATUS_SUCCESS && message_ret) + if ((ret == NOTMUCH_STATUS_SUCCESS || +ret == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) && message_ret) *message_ret = message; else notmuch_message_destroy (message); diff --git a/notmuch-new.c b/notmuch-new.c index 83a05ba..d94ce16 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -19,6 +19,9 @@ */ #include "notmuch-client.h" +#include + +static notmuch_config_t *config = 0; static volatile sig_atomic_t do_add_files_print_progress = 0; @@ -45,6 +48,69 @@ tag_inbox_and_unread (notmuch_message_t *message) notmuch_message_add_tag (message, "unread"); } +/* + * Extracts the sub-directory from the filename and adds it as a new tag to + * the message. The filename must begin with the database directory configured + * in the configuration file. This prefix is then removed. If the remaining + * sub-directory ends with one of the Maildir special directories (/tmp, /new, + * /cur) then they are removed as well. If there is anything left then the + * function adds it as a new tag to the message. + * + * The function does nothing if it cannot extract a sub-directory from + * filename. + */ +static void +subdir_to_tag (char* filename, notmuch_message_t *message) +{ + const char* db_path; + char *msg_dir, *tmp; + int db_path_len, msg_dir_len; + + if (config == NULL) return; +db_path = notmuch_config_get_database_path (config); + if (db_path == NULL) return; + db_path_len = strlen(db_path); + + /* Make a copy of the string as dirname may need to modify it. */ + tmp = talloc_strdup(message, filename); + msg_dir = dirname(tmp); + msg_dir_len = strlen(msg_dir); + + /* If msg_dir starts with db_path, remove it, including the / which delimits +* it from the rest of the directory name. */ + if (db_path_len < msg_dir_len && + !strncmp(db_path, msg_dir, db_path_len)) { + msg_dir += db_path_len + 1; + msg_dir_len -= db_path_len + 1; + } else { + /* If we get here, either the message filename is not inside the +* database directory configured in the configuration file, or it is a +* file in the root directory of the database. Either way we just skip +* it because we do not know how to convert it to a meaningful +* subdirectory string that we could add as tag. */ + goto out; + } + + /* Special conditioning for Maildirs. If the remainder of the directory +* name ends with /new, /cur, or /tmp then remove it. */ + if ((msg_dir_len >= 4) && + (!strncmp(msg_dir + msg_dir_len - 4, "/new", 4) || +!strncmp(msg_dir + msg_dir_len - 4, "/cur", 4) || +!strncmp(msg_dir + msg_dir_len - 4, "/tmp", 4))) { + msg_dir[msg_dir_len - 4] = '\0'; + } + + /* If, after all the modifications, we still have a subdirectory, add it +* as tag. */ + if (strlen(msg_dir)) { + notmuch_message_add_tag (message, msg_dir); + } + +out: + talloc_free(tmp); +} + + static void add_files_print_progress (add_files_state_t *state) { @@ -186,10 +252,15 @@ add_files_recursiv
[notmuch] [PATCH] Error out if no query is supplied to search instead of going into an infinite loop
On Tue, 17 Nov 2009 16:23:53 -0800, Alex Botero-Lowry wrote: > 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 > > 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? Definitely. Priit Laes reported the same thing in IRC and I've just committed a patch to give a nice error message: $ ./notmuch search Error: notmuch search requires at least one search term. Thanks for the report! -Carl
[notmuch] [PATCH] Typsos
On Wed, 18 Nov 2009 00:23:42 +0100, Ingmar Vanhassel wrote: > 17 files changed, 30 insertions(+), 30 deletions(-) Yikes. That's a lot of typos. Thanks Ingmar, for cleaning up after my sloppy keyboarding. Pushed. -Carl
[notmuch] Introducing myself
On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro wrote: > I have just heard about Not Much today in some random Linux-related news > site (LWN?), my name is Adrian Perez and I work as systems administrator Welcome to notmuch, Adrian! We're glad to have you here. > by default on most distribution. I got to have some mailboxes indexed and > basic searching working a couple of months ago. Lately I have been very > busy and had no time for coding, and them... boom! Not Much appears -- and > it is almost exactly what I was trying to do, but faster. I have been > playing a bit with Not Much today, and I think it has potential. It's funny, because I had the exact same experience with sup a couple of months ago. I had been frustrated for years with email programs, and had been thinking about how I'd like things to work n the back of my mind for a long time, (but never *quite* getting to the point where I would commit to writing an email system myself). And then... boom! I found sup and was instantly hooked. It had so much of what I had imagined, (and much of what I hadn't yet imagined) that I was quite delighted. It was really quite by accident that I ended up inventing a different system. I had started out just trying to speedup index creation for sup. If I hadn't run into the problem that it was very difficult[*] to create a sup-compatible index from C code, I might have stopped there. So I'd written a bunch of functional code, only to find myself stuck at the very last step, (hooking it up to the existing sup interface). Then Keith suggested emacs and it all seemed pretty easy since I'd already done all the Xapian work. So it's funny, I was only willing to commit to this project because I wasn't consciously aware I was working on it. Otherwise it would have seemed to overwhelming to start. :-) Anyway, that's a lot of off-topic rambling off of your introduction. But I'm glad that notmuch can now give that same "boom!" to others, and I'm glad you see potential in it. > 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. This way, the index > could be totally recreated by re-reading the mail directories, and this > would also allow to a tools like OfflineIMAP [1] to get the mails into a > local maildir, tagging and indexing the mails with the e-mail reader and > then syncing back the messages with the "X-Tags" header to the IMAP server. > This would allow to use the mail reader from a different computer and still > have everything tagged finely. It is an interesting idea. But there's also something really comforting about the email indexed never modifying the mail files. If you're reading the notmuch commit logs closely you'll see that I'm not actually careful enough to be trusted with your mail (but I try). So I like that I don't even have to trust myself---the worst that happens is that I have to recreate my index. And as Keith mentioned, we've got the "notmuch dump; notmuch restore" idea working exactly as it did in sup. (Though I am thinking of also adding thread IDs to that now---more on that later.) The big annoyance I had with sup index creation, (I ended up having to do it more than once too), was that it takes *forever*. Right now, notmuch is a little bit faster, but not a lot faster. And I've got some ideas to fix that. It would be really nice if index creation were pain free. (And maybe it is for some user with small amounts of mail---oh, to have only 4 messages to have to index!). -Carl [*] The problem here is that sup puts serialized ruby data structures into the data field of its Xapian documents. So being compatible with sup means being able to recreate serialized data structures for a particular version of ruby.
[notmuch] New to the list
On Tue, 17 Nov 2009 23:57:18 +0100, Israel Herraiz wrote: > 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. Welcome, Israel! I'm glad people read that little bit of text in the welcome email and are introducing themselves. I like to think of our new notmuch community as a very personable place. > "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. Yes, take a look. If you're already an emacs user, then you'll find the interface of notmuch very comfortable, (looks a lot like sup, but lives inside of emacs). Even outside of emacs, the command line interface of notmuch gives view *fairly* similar to those of sup: notmuch search tag:inbox# Very much like sup's inbox notmuch show thread:some-thread-id # A lot like sup's thread -view The command-line output right now isn't nearly as neat as sup's, (it doesn't elide comments--it doesn't do the indenting of threads, etc.), even though the command-line interface has all the information it needs to do that. The reason for that is to let the emacs code own most of the formatting, (so that it can be more flexible--such as making hidden things visible, changing column widths, etc.). But one thing I wonder is if there would be situations where it would make sense to get the cleaner output directly out of the command-line tool. For example, for someone who isn't an emacs user, the command-line interface might be their only introduction to what the "notmuch experience" is like. So maybe "notmuch show" should give nice clean output by default and then the emacs code could call "notmuch show --format=emacs-friendly" or something to get the current output. That's an idea anyway. -Carl
[notmuch] [PATCH] Handle rename of message file
If message file has been renamed, just update filename in the DB. Signed-off-by: Mikhail Gusarov --- lib/database.cc | 21 - 1 files changed, 12 insertions(+), 9 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 3c8d626..c4eb8b6 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -925,20 +925,23 @@ notmuch_database_add_message (notmuch_database_t *notmuch, if (private_status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) { _notmuch_message_set_filename (message, filename); _notmuch_message_add_term (message, "type", "mail"); + + ret = _notmuch_database_link_message (notmuch, message, message_file); + if (ret) + goto DONE; + + date = notmuch_message_file_get_header (message_file, "date"); + _notmuch_message_set_date (message, date); + + _notmuch_message_index_file (message, filename); + } else if (strcmp(notmuch_message_get_filename(message), filename)) { + /* Message file has been moved/renamed */ + _notmuch_message_set_filename (message, filename); } else { ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID; goto DONE; } - ret = _notmuch_database_link_message (notmuch, message, message_file); - if (ret) - goto DONE; - - date = notmuch_message_file_get_header (message_file, "date"); - _notmuch_message_set_date (message, date); - - _notmuch_message_index_file (message, filename); - _notmuch_message_sync (message); } catch (const Xapian::Error &error) { fprintf (stderr, "A Xapian exception occurred: %s.\n", -- 1.6.3.3
[notmuch] Working with Maildir storage?
Twas brillig at 15:33:01 17.11.2009 UTC-05 when lars at seas.harvard.edu did gyre and gimble: LK> Is the list archived anywhere? The obvious archives LK> (http://notmuchmail.org/pipermail/notmuch/) aren't available, and I LK> think I subscribed too late to get the patch (I only just saw the LK> discussion about it). LK> It doesn't look like the patch is in git yet. Just has been pushed -- http://fossarchy.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/0e33d964/attachment.pgp>
[notmuch] What a great idea!
On Tue, 17 Nov 2009 23:35:30 +0100, Jan Janak wrote: > 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. Ah, here's where I planned a nice welcome. So welcome (again), Jan! :-) I've been having a lot of fun with notmuch already, (though there have been some days of pain before it was functional enough and my email-reply latency went way up). But regardless---I got through that, and I'm able to work more efficiently with notmuch now than I could with sup before. So I'm happy. And I'm delighted when other people find this interesting as well. > Have you considered sending an announcement to the org-mode mailing list? > http://orgmode.org Thanks for the idea. I think I may have looked into org-mode years ago, (when I was investigating planner-mode and various emacs "personal wiki" systems for keeping random notes and what-not). > 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.. Yeah. I'll drop them a mail. Having a real emacs wizard on board would be nice. (I'm afraid the elisp I've written so far for this project is fairly grim.) -Carl
[notmuch] [PATCH] Older versions of install do not support -C.
On Tue, 17 Nov 2009 23:18:47 +0100, Jan Janak wrote: > 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 Thanks, Jan. This is pushed now. And did I say welcome to notmuch yet? (It's easy to lose track with all the newcomers---which I'm not complaining about---especially since so many are sharing code.) -Carl PS. I actually really like the behavior of -C (especially when installing a low-level library to avoid big waterfalls of needless recompiles). But since we're *not* actually installing a library (yet) I'm happy with this patch rather than writing code in configure to check if "install -C" works or not.
[notmuch] archive
On Tue, 17 Nov 2009 18:04:31 -0800, Keith Packard wrote: > 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. Fixed it in transit in Frankfurt---with only moments to spare on my battery and no outlets in sight. Thanks for the report, Aron. And welcome to notmuch! -Carl (who wants to reply to a lot more mail, but will have to wait until later for that)
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Tue, 17 Nov 2009 13:32:45 -0800, Keith Packard wrote: > 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. I don't like this---but that's because I use 'x' precisely *because* it preserves these tags. Otherwise, you might as well just remove inbox and unread as soon as the message is presented to the user. And that's a bug in a lot of other email programs that I'm unwilling to replicate. We may run into a need to define different ways that people like to work with their email here. (I know that so far I've just been coding up the way I want my mail to work.) -Carl
[notmuch] Working with Maildir storage?
On Tue, 17 Nov 2009 14:00:54 -0500, Lars Kellogg-Stedman wrote: > 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). Welcome, Lars! I hadn't even seen that Keith's blog post had been picked up by lwn.net. That's very interesting. So, thanks for coming and trying out notmuch. > Error opening > > /home/lars/Mail/read-messages.2008/cur/1246413773.24928_27334.hostname,U=3026:2,S: > Too many open files Sadly, the lwn article coincided with me having just introduced this bug, and then getting on a Trans-Atlantic flight. So I fixed the bug fairly quickly, but there was quite a bit of latency before I could push the fix out. It should be fixed now. > I'm curious if this is expected behavior (i.e., notmuch does not work > with Maildir) or if something else is going on. Notmuch works just fine with maildir---it's one of the things that it likes the best. Happy hacking, -Carl
[notmuch] [PATCH 1/2] Close message file after parsing message headers
On Tue, 17 Nov 2009 13:15:25 -0800, Keith Packard wrote: > 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... Hi Keith, Once I finally got back on the ground again, I pushed out a revised version of your patch, (didn't need the reply-to stuff anymore since I had fixed that differently in the meantime). I'm pretty happy with the state of this portion of the code now. Thanks Keith and Mikhail for your input on and code to fix this bug. -Carl
[notmuch] Working with Maildir storage?
Twas brillig at 14:00:54 17.11.2009 UTC-05 when lars at seas.harvard.edu did gyre and gimble: LK> Resulted in 4604 lines of errors along the lines of: LK> Error opening LK> /home/lars/Mail/read-messages.2008/cur/1246413773.24928_27334.hostname,U=3026:2,S: LK> Too many open files See the patch just posted here. -- http://fossarchy.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/60743c36/attachment.pgp>
[notmuch] [PATCH] Create a default notmuch-show-hook that highlights URLs and uses word-wrap
On Wed, 18 Nov 2009 00:29:59 -0800, Keith Packard wrote: > I created the notmuch-show-hook precisely so I could add these two > options, but I suspect most people will want them, so I just made them > the default. If you don't want them, you can use remove-hook to get > rid of this. > Yes, hooks should be added for search as well. :) > +; Make show mode a bit prettier, highlighting URLs and using word wrap > + > +(defun notmuch-show-pretty-hook () > + (goto-address-mode 1) > + (visual-line-mode)) > + visual-line-mode turns out to make subject look pretty ugly if there is a continuation. It doesn't do much good for the citation headers either. We probably need to do our own intelligent wrapping rather then use visual-line-mode to make this actually look right. goto-address-mode is important though. :) alex
[notmuch] [PATCH] Create a default notmuch-show-hook that highlights URLs and uses word-wrap
I created the notmuch-show-hook precisely so I could add these two options, but I suspect most people will want them, so I just made them the default. If you don't want them, you can use remove-hook to get rid of this. Signed-off-by: Keith Packard --- notmuch.el |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index 1bb1294..c95cb43 100644 --- a/notmuch.el +++ b/notmuch.el @@ -698,6 +698,14 @@ view, (remove the \"inbox\" tag from each), with either :options '(goto-address) :group 'notmuch) +; Make show mode a bit prettier, highlighting URLs and using word wrap + +(defun notmuch-show-pretty-hook () + (goto-address-mode 1) + (visual-line-mode)) + +(add-hook 'notmuch-show-hook 'notmuch-show-pretty-hook) + (defun notmuch-show (thread-id &optional parent-buffer) "Run \"notmuch show\" with the given thread ID and display results. -- 1.6.5.2
[notmuch] [PATCH] Typsos
--- Makefile|4 ++-- README |6 +++--- gmime-filter-reply.h|2 +- lib/database.cc |2 +- lib/index.cc|2 +- lib/message.cc |2 +- lib/messages.c |2 +- lib/notmuch-private.h |2 +- lib/notmuch.h | 10 +- lib/sha1.c |2 +- lib/thread.cc |2 +- notmuch-completion.bash |2 +- notmuch-new.c |4 ++-- notmuch-search.c|2 +- notmuch.1 |4 ++-- notmuch.el | 10 +- show-message.c |2 +- 17 files changed, 30 insertions(+), 30 deletions(-) diff --git a/Makefile b/Makefile index 436dacf..96aaa73 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -# Default FLAGS, (can be overriden by user such as "make CFLAGS=-O2") +# Default FLAGS, (can be overridden by user such as "make CFLAGS=-O2") WARN_FLAGS=-Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum CFLAGS=-O2 @@ -14,7 +14,7 @@ override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) $(extra_cxxflags) override LDFLAGS += `pkg-config --libs glib-2.0 gmime-2.4 talloc` \ `xapian-config --libs` -# Include our local Makfile.local first so that its first target is default +# Include our local Makefile.local first so that its first target is default include Makefile.local include lib/Makefile.local diff --git a/README b/README index 40f05ab..27af77f 100644 --- a/README +++ b/README @@ -3,7 +3,7 @@ Notmuch - thread-based email index, search and tagging. Notmuch is a system for indexing, searching, reading, and tagging large collections of email messages. It uses the Xapian library to provide fast, full-text search of very large collection of email with -a very convenient search syntas. +a very convenient search syntax. Notmuch is free software, released under the GNU General Public License version 3 (or later). @@ -45,7 +45,7 @@ obtaining a more sophisticated interface: notmuch.el file in this distribution. If someone were to write a curses-based interface, or similar, - it might also be reasonable to buil on the "notmuch" + it might also be reasonable to build on the "notmuch" command-line interface. 2. Build on top of the notmuch library interface. @@ -67,4 +67,4 @@ still in development. We would appreciate any contributions to these efforts. - \ No newline at end of file + diff --git a/gmime-filter-reply.h b/gmime-filter-reply.h index 41cbc13..b7cbc6b 100644 --- a/gmime-filter-reply.h +++ b/gmime-filter-reply.h @@ -40,7 +40,7 @@ typedef struct _GMimeFilterReplyClass GMimeFilterReplyClass; * @saw_nl: previous char was a \n * @saw_angle: previous char was a > * - * A filter to insert/remove reply markers (lines begining with >) + * A filter to insert/remove reply markers (lines beginning with >) **/ struct _GMimeFilterReply { GMimeFilter parent_object; diff --git a/lib/database.cc b/lib/database.cc index 3c8d626..27597cf 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -180,7 +180,7 @@ notmuch_status_to_string (notmuch_status_t status) case NOTMUCH_STATUS_TAG_TOO_LONG: return "Tag value is too long (exceeds NOTMUCH_TAG_MAX)"; case NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW: - return "Unblanced number of calls to notmuch_message_freeze/thaw"; + return "Unbalanced number of calls to notmuch_message_freeze/thaw"; default: case NOTMUCH_STATUS_LAST_STATUS: return "Unknown error status value"; diff --git a/lib/index.cc b/lib/index.cc index 65b83b3..80df64b 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -198,7 +198,7 @@ _index_mime_part (notmuch_message_t *message, if (i == 1) continue; if (i > 1) - fprintf (stderr, "Warning: Unexpected extra parts of mutlipart/signed. Indexing anyway.\n"); + fprintf (stderr, "Warning: Unexpected extra parts of multipart/signed. Indexing anyway.\n"); } _index_mime_part (message, g_mime_multipart_get_part (multipart, i)); diff --git a/lib/message.cc b/lib/message.cc index a4b090b..1d6623f 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -144,7 +144,7 @@ _notmuch_message_create (const void *talloc_owner, } /* Create a new notmuch_message_t object for a specific message ID, - * (which may or may not already exist in the databas). + * (which may or may not already exist in the database). * * Here, 'talloc owner' is an optional talloc context to which the new * message will belong. This allows for the caller to not bother diff --git a/lib/messages.c b/lib/messages.c index a588f8f..2f7c283 100644 --- a/lib/messages.c +++ b/lib/messages.c @@ -47,7 +47,7 @@ _notmuch_message_list_create (const void *ctx) return list; } -/* Append 'node' (which can of course point to an aribtrarily lo
[notmuch] Introducing myself
Hello to all, I have just heard about Not Much today in some random Linux-related news site (LWN?), my name is Adrian Perez and I work as systems administrator (although I can do some code as well :P). I have always thought that the ideas behind Sup were great, but after some time using it, I got tired of the oddities that it has. I also do not like doing things like having to install Ruby just for reading and sorting mails. 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. Lately I have been very busy and had no time for coding, and them... boom! Not Much appears -- and it is almost exactly what I was trying to do, but faster. I have been playing a bit with Not Much today, and I think it has potential. 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. This way, the index could be totally recreated by re-reading the mail directories, and this would also allow to a tools like OfflineIMAP [1] to get the mails into a local maildir, tagging and indexing the mails with the e-mail reader and then syncing back the messages with the "X-Tags" header to the IMAP server. This would allow to use the mail reader from a different computer and still have everything tagged finely. Best regards, --- [1] http://software.complete.org/software/projects/show/offlineimap -- Adrian Perez de Castro Igalia - Free Software Engineering -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091118/88190837/attachment-0001.pgp>
[notmuch] request for pull
The following changes since commit e8c9c3e6a534fc6c2919c2c1de63cea7250eb488: Ingmar Vanhassel (1): Makefile: Manual pages shouldn't be executable are available in the git repository at: git://alexbl.net/notmuch.git master Alexander Botero-Lowry (2): Error out if no query is supplied to search instead of going into an infinite loop set a local truncate-line variable in notmuch-search-mode, so that subjects don't wrap and make the output look weird notmuch-search.c |5 + notmuch.el |1 + 2 files changed, 6 insertions(+), 0 deletions(-)