[notmuch] [PATCH] Makefile: Magic silent rules.
Twas brillig at 19:02:22 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did gyre and gimble: CW> Use the facilities of GNU make to create a magic function that will CW> on the first invocation print a description of how to enable CW> verbose compile lines and then print the quiet rule. Ugh. With silent rules enabled it gives me /bin/sh: --rsyncable: not found at the end (apparently gzip was eaten out) And with V=1 it strips first two symbols from the command name: c -Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gmime-2.4 -Ilib lib/query.cc -o lib/query.o make: c: Command not found make: [lib/query.o] Error 127 (ignored) c -Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gmime-2.4 -Ilib lib/thread.cc -o lib/thread.o make: c: Command not found make: [lib/thread.o] Error 127 (ignored) rcs lib/notmuch.a lib/libsha1.o lib/message-file.o lib/messages.o lib/sha1.o lib/tags.o lib/xutil.o lib/database.o lib/index.o lib/message.o lib/query.o lib/thread.o make: rcs: Command not found -- 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/20091122/83d17991/attachment.pgp>
[notmuch] [PATCH] Makefile: Magic silent rules.
Twas brillig at 20:32:20 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did gyre and gimble: CW> Use the facilities of GNU make to create a magic function that will CW> on the first invocation print a description of how to enable CW> verbose compile lines and then print the quiet rule. Uhm. Now it eats much less :) $ make ... GZIP notmuch.1.gz /bin/sh: --rsyncable: not found make: *** [notmuch.1.gz] Error 127 $ $ make V=1 ... rsyncable --stdout notmuch.1 > notmuch.1.gz /bin/sh: rsyncable: not found make: [notmuch.1.gz] Error 127 (ignored) $ -- 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/20091122/76c25d69/attachment.pgp>
[notmuch] [PATCH] notmuch new: Support for conversion of spool subdirectories into tags
On Sat, Nov 21, 2009 at 7:44 PM, Carl Worth wrote: > On Wed, 18 Nov 2009 05:57:03 +0100, Jan Janak wrote: >> 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. > > Hi Jan, > > I just pushed out a patch from Aneesh for similar functionality, but > with a simpler implementation. > > One thing that patch loses is the addition of multiple tags when a > message appears in multiple directories. Would you like to code up that > feature on top of the current code? Looking at the commit log history, I noticed that you reverted the commit, so I guess this question is no more relevant. By the way, although I provided a similar patch some time ago, I agree that it is better not to have this hard-wired in 'notmuch-new'. It helped me with the initial import, but since then I have been trying to get it working with a script run after 'notmuch-new'. -- Jan
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sat, 21 Nov 2009 22:07:14 +0100, Jan Janak wrote: > My patch no longer works and I have been thinking about updating it to > current HEAD. But before I do that, I wanted to check with you to see > if you would prefer to use a different name for the command, here are > some options: > > 1) notmuch tags > 2) notmuch list tags > 3) notmuch list-tag > > Any opinions? > > I also plan to add support for search-terms later so that we can > produce tag lists for a set of messages, as you mentioned in one of > your previous emails. I don't think "list" would make sense unless it didn't support search terms at all. So I proposed my "search-messages" command earlier as well. It's clear that there are lots of different things that we're going to want to search for in the database and then lots of way's that we're going to want to present the resulting data. I would rather like there to be some correlation between commands with shorter names being more likely to be the kind of thing that a user would use directly from the command line. And longer names can be used for things that are more for interfaces to use, and for people to use in writing scripts. So how about "search-tags" and "search-messages" ? Any better ideas? Another option would be to just call this "notmuch search" and have an option to control what is output: notmuch search # for threads, as currently notmuch search --output=tags notmuch search --output=messages Actually, I kind of like that. For one thing, it makes it easy to eliminate the redundancy I made with the option-parsing in both notmuch-search.c and notmuch-search-message.c. > A quick description for those who joined later: This command produces > a list of all tags defined in the database. The emacs interface uses > it to implement tag name completion. And I can't wait to have tag completion in the interface. This will be nice. One thing we'll still have to think about is how to remove the "virtual tags" from the completion list, (once we have virtual tags in the configuration file---that is, tags applied automatically based on search specifications). The place we'd want to remove these from the completion list is when adding/removing a tag---it should be illegal to add/remove virtual tags since they will be maintained by the system according to the search specifications. Of course, when searching/filtering by tag, the completion list should include all tags, whether manual or virtual. So, what we're going to need for that is something like "notmuch config" that allows the interface to query the configuration. But that's all down the road. Let's get that tag completion working! -Carl
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth wrote: > One thing we'll still have to think about is how to remove the "virtual > tags" from the completion list, (once we have virtual tags in the > configuration file---that is, tags applied automatically based on search > specifications). Do these need to be real tags? Would it be sufficient for them to just be aliases for search patterns? I think I would prefer the latter because I could modify the pattern and not have to rewrite tags to the whole database. Maybe real tags are needed to optimize expensive patterns, but I wouldn't think the user needs to know about that. Jed
[notmuch] [PATCH] notmuch-config: Fix memleaks.
On Sat, 21 Nov 2009 23:17:02 +0100, Stefan Schmidt wrote: > > While talloc is great we need to free the g_error by hand. > > Tested-by: Stefan Schmidt > Signed-off-by: Holger Freyther Thanks to both of you! This is pushed. As for talloc and glib, it's become clear to me that I'd really like a talloc-friendly hash-table implementation, (and maybe a nice growing array). I really haven't seen any other data structures in glib that I'd need as universally as I need those, (particularly since talloc already provides a bunch of string functions). -Carl
[notmuch] [PATCH 2/2] notmuch-new: Tag mails not as unread when the seen flag in the maildir is set.
With the new notmuch_message_get_flags() function we can get the information if
a message was already flagged as seen in maildir by another mailer or tool. This
gives a more realistic picture instead of flagging all as unread.
Signed-off-by: Stefan Schmidt
---
Makefile |2 +-
notmuch-new.c | 16 +++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3fedcf1..dfcfc70 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
# Default FLAGS, (can be overridden by user such as "make CFLAGS=-O2")
WARN_FLAGS=-Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum
-CFLAGS=-O2
+CFLAGS=-O0 -ggdb3
# Additional flags that we will append to whatever the user set.
# These aren't intended for the user to manipulate.
diff --git a/notmuch-new.c b/notmuch-new.c
index bc35b4e..ef4429d 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -41,8 +41,22 @@ handle_sigint (unused (int sig))
static void
tag_inbox_and_unread (notmuch_message_t *message)
{
-notmuch_message_add_tag (message, "inbox");
+char *buf;
+int i;
+
+buf = notmuch_message_get_flags (message);
+for (i = 0; i < strlen (buf); i++) {
+/* If the S flag is set the message can be tagged as read */
+if (buf[i] == 'S') {
+notmuch_message_add_tag (message, "read");
+goto inbox;
+}
+}
+
notmuch_message_add_tag (message, "unread");
+
+inbox:
+notmuch_message_add_tag (message, "inbox");
}
static void
--
1.6.5.3
[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.
With notmuch_message_get_flags() we gain the information if the message was
flagged as read, draft, trashed, etc. Handy for big mail spooles that were used
with another mailer.
Signed-off-by: Stefan Schmidt
---
lib/message.cc | 26 ++
lib/notmuch.h | 10 ++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 069cedb..9bec61e 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
char *thread_id;
char *in_reply_to;
char *filename;
+char *flags;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
@@ -114,6 +115,7 @@ _notmuch_message_create (const void *talloc_owner,
message->thread_id = NULL;
message->in_reply_to = NULL;
message->filename = NULL;
+message->flags = NULL;
message->message_file = NULL;
message->replies = _notmuch_message_list_create (message);
@@ -438,6 +440,30 @@ notmuch_message_get_filename (notmuch_message_t *message)
return message->filename;
}
+const char *
+notmuch_message_get_flags (notmuch_message_t *message)
+{
+std::string filename_str, flags;
+size_t position;
+const char *db_path;
+
+if (message->flags)
+ return message->flags;
+
+filename_str = message->doc.get_data ();
+db_path = notmuch_database_get_path (message->notmuch);
+
+if (filename_str[0] != '/')
+ filename_str.insert (0, db_path);
+
+/* Flags are everything behind ":" */
+position = filename_str.find (":");
+flags = filename_str.substr (position + 3); /* We don't want :2, */
+message->flags = talloc_strdup (message, flags.c_str ());
+
+return message->flags;
+}
+
time_t
notmuch_message_get_date (notmuch_message_t *message)
{
diff --git a/lib/notmuch.h b/lib/notmuch.h
index a61cd02..1da5dfd 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -694,6 +694,16 @@ notmuch_message_get_replies (notmuch_message_t *message);
const char *
notmuch_message_get_filename (notmuch_message_t *message);
+/* Get the maildir flags for the email corresponding to 'message'.
+ *
+ * The returned flags will be a string of ascii format flags.
+ *
+ * The returned string belongs to the message so should not be
+ * modified or freed by the caller (nor should it be referenced after
+ * the message is destroyed). */
+const char *
+notmuch_message_get_flags (notmuch_message_t *message);
+
/* Get the date of 'message' as a time_t value.
*
* For the original textual representation of the Date header from the
--
1.6.5.3
[notmuch] [PATCH] notmuch-new: Only install SIGALRM if not running under gdb
I felt sorry for Carl trying to step through an exception from xapian and suffering from the SIGALARMs.. We can detect if the user launched notmuch under a debugger by either checking our cmdline for the presence of the gdb string or querying if valgrind is controlling our process. For the latter we need to add a compile time check for the valgrind development library, and so add the initial support to build Makefile.config from configure. Signed-off-by: Chris Wilson Reviewed-by: Carl Worth --- Makefile.config |1 + Makefile.local |3 ++- configure| 21 + debugger.c | 47 +++ notmuch-client.h |3 +++ notmuch-new.c| 12 +++- 6 files changed, 77 insertions(+), 10 deletions(-) create mode 100644 debugger.c diff --git a/Makefile.config b/Makefile.config index d72a39e..ddc7436 100644 --- a/Makefile.config +++ b/Makefile.config @@ -1,2 +1,3 @@ prefix = /usr/local bash_completion_dir = /etc/bash_completion.d +CFLAGS += -DHAVE_VALGRIND diff --git a/Makefile.local b/Makefile.local index 3c99624..efe76c8 100644 --- a/Makefile.local +++ b/Makefile.local @@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz emacs: notmuch.elc notmuch_client_srcs = \ + debugger.c \ + gmime-filter-reply.c\ notmuch.c \ notmuch-config.c\ notmuch-dump.c \ @@ -14,7 +16,6 @@ notmuch_client_srcs = \ notmuch-show.c \ notmuch-tag.c \ notmuch-time.c \ - gmime-filter-reply.c\ query-string.c \ show-message.c diff --git a/configure b/configure index fe46c8e..b4770ec 100755 --- a/configure +++ b/configure @@ -53,6 +53,14 @@ else errors=$((errors + 1)) fi +if pkg-config --modversion valgrind > /dev/null 2>&1; then +echo "Checking for valgrind development files... Yes." +have_valgrind=-DHAVE_VALGRIND +else +echo "Checking for valgrind development files... No." +have_valgrind= +fi + if [ $errors -gt 0 ]; then cat < Makefile.config
[notmuch] [PATCH] notmuch-new: Only install SIGALRM if not running under gdb
I felt sorry for Carl trying to step through an exception from xapian and suffering from the SIGALARMs.. We can detect if the user launched notmuch under a debugger by either checking our cmdline for the presence of the gdb string or querying if valgrind is controlling our process. For the latter we need to add a compile time check for the valgrind development library, and so add the initial support to build Makefile.config from configure. Signed-off-by: Chris Wilson Reviewed-by: Carl Worth [ickle: And do not install the timer] --- Makefile.config |1 + Makefile.local |3 ++- configure| 21 + debugger.c | 47 +++ notmuch-client.h |3 +++ notmuch-new.c| 12 +++- 6 files changed, 77 insertions(+), 10 deletions(-) create mode 100644 debugger.c diff --git a/Makefile.config b/Makefile.config index d72a39e..ddc7436 100644 --- a/Makefile.config +++ b/Makefile.config @@ -1,2 +1,3 @@ prefix = /usr/local bash_completion_dir = /etc/bash_completion.d +CFLAGS += -DHAVE_VALGRIND diff --git a/Makefile.local b/Makefile.local index 3c99624..efe76c8 100644 --- a/Makefile.local +++ b/Makefile.local @@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz emacs: notmuch.elc notmuch_client_srcs = \ + debugger.c \ + gmime-filter-reply.c\ notmuch.c \ notmuch-config.c\ notmuch-dump.c \ @@ -14,7 +16,6 @@ notmuch_client_srcs = \ notmuch-show.c \ notmuch-tag.c \ notmuch-time.c \ - gmime-filter-reply.c\ query-string.c \ show-message.c diff --git a/configure b/configure index fe46c8e..b4770ec 100755 --- a/configure +++ b/configure @@ -53,6 +53,14 @@ else errors=$((errors + 1)) fi +if pkg-config --modversion valgrind > /dev/null 2>&1; then +echo "Checking for valgrind development files... Yes." +have_valgrind=-DHAVE_VALGRIND +else +echo "Checking for valgrind development files... No." +have_valgrind= +fi + if [ $errors -gt 0 ]; then cat < Makefile.config
[notmuch] Avoid installing SIGALRMs when under the debugger.
Gah, I'm tired and using "git send-email HEAD^" is too easy. Here is the most recent pair of patches in possibly a working state. -ickle
[notmuch] [PATCH 1/2] notmuch-new: Only install SIGALRM if not running under gdb
I felt sorry for Carl trying to step through an exception from xapian and suffering from the SIGALARMs.. We can detect if the user launched notmuch under a debugger by either checking our cmdline for the presence of the gdb string or querying if valgrind is controlling our process. For the latter we need to add a compile time check for the valgrind development library, and so add the initial support to build Makefile.config from configure. Signed-off-by: Chris Wilson Reviewed-by: Carl Worth [ickle: And do not install the timer when under the debugger] --- Makefile.config |1 + Makefile.local |3 ++- configure| 21 + debugger.c | 47 +++ notmuch-client.h |3 +++ notmuch-new.c| 49 - 6 files changed, 98 insertions(+), 26 deletions(-) create mode 100644 debugger.c diff --git a/Makefile.config b/Makefile.config index d72a39e..ddc7436 100644 --- a/Makefile.config +++ b/Makefile.config @@ -1,2 +1,3 @@ prefix = /usr/local bash_completion_dir = /etc/bash_completion.d +CFLAGS += -DHAVE_VALGRIND diff --git a/Makefile.local b/Makefile.local index 3c99624..efe76c8 100644 --- a/Makefile.local +++ b/Makefile.local @@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz emacs: notmuch.elc notmuch_client_srcs = \ + debugger.c \ + gmime-filter-reply.c\ notmuch.c \ notmuch-config.c\ notmuch-dump.c \ @@ -14,7 +16,6 @@ notmuch_client_srcs = \ notmuch-show.c \ notmuch-tag.c \ notmuch-time.c \ - gmime-filter-reply.c\ query-string.c \ show-message.c diff --git a/configure b/configure index fe46c8e..b4770ec 100755 --- a/configure +++ b/configure @@ -53,6 +53,14 @@ else errors=$((errors + 1)) fi +if pkg-config --modversion valgrind > /dev/null 2>&1; then +echo "Checking for valgrind development files... Yes." +have_valgrind=-DHAVE_VALGRIND +else +echo "Checking for valgrind development files... No." +have_valgrind= +fi + if [ $errors -gt 0 ]; then cat < Makefile.config
[notmuch] [PATCH 2/2] notmuch-new: Only print the regular progress report when on a tty
Check that the stdout is connected to an interactive terminal with
isatty() before installing the periodic timer to print progress reports.
Signed-off-by: Chris Wilson
---
notmuch-new.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 1616ee9..0dd2784 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -20,6 +20,8 @@
#include "notmuch-client.h"
+#include
+
static volatile sig_atomic_t do_add_files_print_progress = 0;
static void
@@ -273,7 +275,7 @@ add_files (notmuch_database_t *notmuch,
}
/* Setup our handler for SIGALRM */
-if (! debugger_is_active ()) {
+if (isatty (fileno (stdout)) && ! debugger_is_active ()) {
memset (&action, 0, sizeof (struct sigaction));
action.sa_handler = handle_sigalrm;
sigemptyset (&action.sa_mask);
--
1.6.5.3
[notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.
The majority of filenames will fit within PATH_MAX [4096] (because
that's a hard limit imposed by the filesystems) so we can avoid an
allocation per lookup and thereby eliminate a large proportion of the
overhead of scanning a maildir.
Signed-off-by: Chris Wilson
---
notmuch-new.c | 75 ++--
1 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..13559d1 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -107,6 +107,7 @@ add_files_recursive (notmuch_database_t *notmuch,
add_files_state_t *state)
{
DIR *dir = NULL;
+char buf[4096];
struct dirent *entry = NULL;
char *next = NULL;
time_t path_mtime, path_dbtime;
@@ -114,6 +115,7 @@ add_files_recursive (notmuch_database_t *notmuch,
notmuch_message_t *message = NULL;
struct dirent **namelist = NULL;
int num_entries;
+int path_len, dname_len;
/* If we're told to, we bail out on encountering a read-only
* directory, (with this being a clear clue from the user to
@@ -140,6 +142,12 @@ add_files_recursive (notmuch_database_t *notmuch,
int i=0;
+path_len = strlen (path);
+if (path_len + 2 < (int) sizeof (buf)) {
+ memcpy (buf, path, path_len);
+ buf[path_len] = '/';
+}
+
while (!interrupted) {
if (i == num_entries)
break;
@@ -164,37 +172,42 @@ add_files_recursive (notmuch_database_t *notmuch,
continue;
}
- next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
+ dname_len = strlen (entry->d_name);
+ if (path_len + dname_len + 2 < (int) sizeof (buf)) {
+ memcpy (buf + path_len + 1, entry->d_name, dname_len);
+ buf[path_len + dname_len + 1] = '\0';
+ next = buf;
+ } else {
+ next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
+ }
if (stat (next, st)) {
fprintf (stderr, "Error reading %s: %s\n",
next, strerror (errno));
ret = NOTMUCH_STATUS_FILE_ERROR;
- continue;
- }
-
- if (S_ISREG (st->st_mode)) {
- /* If the file hasn't been modified since the last
-* add_files, then we need not look at it. */
- if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
- state->processed_files++;
-
- status = notmuch_database_add_message (notmuch, next, &message);
- switch (status) {
- /* success */
+ } else {
+ if (S_ISREG (st->st_mode)) {
+ /* If the file hasn't been modified since the last
+* add_files, then we need not look at it. */
+ if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
+ state->processed_files++;
+
+ status = notmuch_database_add_message (notmuch, next,
&message);
+ switch (status) {
+ /* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
tag_inbox_and_unread (message);
break;
- /* Non-fatal issues (go on to next file) */
+ /* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
- /* Stay silent on this one. */
+ /* Stay silent on this one. */
break;
case NOTMUCH_STATUS_FILE_NOT_EMAIL:
fprintf (stderr, "Note: Ignoring non-mail file: %s\n",
next);
break;
- /* Fatal issues. Don't process anymore. */
+ /* Fatal issues. Don't process anymore. */
case NOTMUCH_STATUS_READONLY_DATABASE:
case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
case NOTMUCH_STATUS_OUT_OF_MEMORY:
@@ -210,25 +223,27 @@ add_files_recursive (notmuch_database_t *notmuch,
case NOTMUCH_STATUS_LAST_STATUS:
INTERNAL_ERROR ("add_message returned unexpected value:
%d", status);
goto DONE;
- }
+ }
- if (message) {
- notmuch_message_destroy (message);
- message = NULL;
- }
+ if (message) {
+ notmuch_message_destroy (message);
+ message = NULL;
+ }
- if (do_add_files_print_progress) {
- do_add_files_print_progress = 0;
- add_files_print_progress (state);
+ if (do_add_files_print_progress) {
+ do_add_files_print_progress = 0;
+ add_files_print_progress (state);
+
[notmuch] [PATCH] Mac OS X compatibility fixes
Add missing GNU extensions strdup() and getline(). The C library
shipped with Mac OS X does not include them (though it does support
some GNU extensions when _GNU_SOURCE is defined), so we have to
add these two. The getline() implementation is a modified version
of getdelim() from GNU Libc.
---
lib/xutil.c | 99 +++
lib/xutil.h |6 +++
2 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/lib/xutil.c b/lib/xutil.c
index 6fa5eb0..805b236 100644
--- a/lib/xutil.c
+++ b/lib/xutil.c
@@ -79,6 +79,105 @@ xstrdup (const char *s)
return ret;
}
+#ifdef __APPLE__
+/* Mac OS X don't have strndup even if _GNU_SOURCE is defined */
+char *strndup (const char *s, size_t n)
+{
+size_t len = strlen (s);
+char *ret;
+
+if (len <= n)
+ return strdup (s);
+
+ret = malloc(n + 1);
+strncpy(ret, s, n);
+ret[n] = '\0';
+return ret;
+}
+
+/* getline implementation is copied from glibc. */
+
+#ifndef SIZE_MAX
+# define SIZE_MAX ((size_t) -1)
+#endif
+#ifndef SSIZE_MAX
+# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
+#endif
+
+ssize_t getline (char **lineptr, size_t *n, FILE *fp)
+{
+ssize_t result;
+size_t cur_len = 0;
+
+if (lineptr == NULL || n == NULL || fp == NULL)
+{
+ errno = EINVAL;
+ return -1;
+}
+
+if (*lineptr == NULL || *n == 0)
+{
+ *n = 120;
+ *lineptr = (char *) malloc (*n);
+ if (*lineptr == NULL)
+ {
+ result = -1;
+ goto end;
+ }
+}
+
+for (;;)
+{
+ int i;
+
+ i = getc (fp);
+ if (i == EOF)
+ {
+ result = -1;
+ break;
+ }
+
+ /* Make enough space for len+1 (for final NUL) bytes. */
+ if (cur_len + 1 >= *n)
+ {
+ size_t needed_max =
+ SSIZE_MAX < SIZE_MAX ? (size_t) SSIZE_MAX + 1 : SIZE_MAX;
+ size_t needed = 2 * *n + 1; /* Be generous. */
+ char *new_lineptr;
+
+ if (needed_max < needed)
+ needed = needed_max;
+ if (cur_len + 1 >= needed)
+ {
+ result = -1;
+ goto end;
+ }
+
+ new_lineptr = (char *) realloc (*lineptr, needed);
+ if (new_lineptr == NULL)
+ {
+ result = -1;
+ goto end;
+ }
+
+ *lineptr = new_lineptr;
+ *n = needed;
+ }
+
+ (*lineptr)[cur_len] = i;
+ cur_len++;
+
+ if (i == '\n')
+ break;
+}
+(*lineptr)[cur_len] = '\0';
+result = cur_len ? (ssize_t) cur_len : result;
+
+end:
+return result;
+}
+#endif
+
char *
xstrndup (const char *s, size_t n)
{
diff --git a/lib/xutil.h b/lib/xutil.h
index b973f7d..0b53f7c 100644
--- a/lib/xutil.h
+++ b/lib/xutil.h
@@ -25,6 +25,12 @@
#include
#include
+#ifdef __APPLE__
+/* Mac OS X don't have strndup and getline even if _GNU_SOURCE is defined */
+char *strndup (const char *s, size_t n);
+ssize_t getline(char **lineptr, size_t *n, FILE *stream);
+#endif
+
/* xutil.c */
void *
xcalloc (size_t nmemb, size_t size);
--
1.6.4
[notmuch] Segfault with weird Message-ID
On Sat, 21 Nov 2009 23:26:15 +0100, Mike Hommey
wrote:
> I just was able to reproduce after starting over.
Thanks Mike. I was able to reproduce this as well by eliminating the
spurious blank line I had on the 2nd or 3rd line. (So maybe that managed
to sneak in when you sent me the message.)
> header isn't "", and message_id is correctly filled. I can also confirm
> the exception is thrown from notmuch->xapian_db->add_document.
Yes. We were trying to add a term that is too long for Xapian. I've
fixed this by simply falling back to our existing sha-1 code when a
message ID is long.
Thanks so much for the bug report!
-Carl
commit 5d56e931b99d575dbb0b936d24aae5e9903861ad
Author: Carl Worth
Date: Sun Nov 22 04:03:49 2009 +0100
add_message: Use sha-1 in place of overly long message ID.
Since Xapian has a limit on the maximum length of a term, we have
to check for that before trying to add the message ID as a term.
This fixes the bug reported by Mike Hommey here:
<20091120132625.GA19246 at glandium.org>
I've also constructed 20 files with a range of message ID lengths
centered around the Xapian term-length limit which I'll use to seed a
new test suite soon.
diff --git a/lib/database.cc b/lib/database.cc
index 169dc5e..f4a445a 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -892,7 +892,7 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
const char *date, *header;
const char *from, *to, *subject;
-char *message_id;
+char *message_id = NULL;
if (message_ret)
*message_ret = NULL;
@@ -937,11 +937,20 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
header = notmuch_message_file_get_header (message_file, "message-id");
if (header && *header != '\0') {
message_id = _parse_message_id (message_file, header, NULL);
+
/* So the header value isn't RFC-compliant, but it's
* better than no message-id at all. */
if (message_id == NULL)
message_id = talloc_strdup (message_file, header);
- } else {
+
+ /* Reject a Message ID that's too long. */
+ if (message_id && strlen (message_id) + 1 > NOTMUCH_TERM_MAX) {
+ talloc_free (message_id);
+ message_id = NULL;
+ }
+ }
+
+ if (message_id == NULL ) {
/* No message-id at all, let's generate one by taking a
* hash over the file's contents. */
char *sha1 = notmuch_sha1_of_file (filename);
[notmuch] 25 minutes load time with emacs -f notmuch
On Sat, 21 Nov 2009 17:36:18 -0500, Brett Viren wrote: > Processed 130871 total files in 38m 7s (57 files/sec.). > Added 102723 new messages to the database (not much, really). Just be glad that you have so little mail. ;-) > This was ~2GB of mail on a 2.5GHz CPU. That seems pretty reasonable > to me but I'd like to rerun the "notmuch new" under google perftools > to see if there are any obvious bottlenecks that might be cleaned up. To me, here are the obvious things to fix after looking at a profile: 1. We're spending a *lot* of time searching in the Xapian database. But our initial indexing operation should only be *writing* data into the database, so what's this searching about? Well, at each new message, we're looking up the ID from it's In-Reply-To header to find a thread-ID to link to, and then we're looking up all of the IDs from its References header to find thread IDs that need to be merged with ours. So both parent and child lookups. And since those are taking a bunch of time, I think it might make sense to just keep a hashtable mapping message-ID -> thread-ID and do lookups in that, (should have plenty of memory on current machines even with lots of mail). 2. We're hitting the slow Xapian document updates for thread-ID merging. Whenever we find a child that was already in the database with one thread ID that should have ours, we simply want to set its thread ID to ours. But as we've talked about recently, Xapian has a bug (defect 250) that makes it much more expensive than it should be to update a single term. So, we could do a first pass over the messages to find all their thread IDs and get them to settle down before doing any indexing in a separate, second pass. Step (2) should help even if we don't do step (1), but clearly we can do both. It would be great if anyone wants to take a look at either or both of these, otherwise I will when I can. -Carl
[notmuch] [PATCH] Makefile: Magic silent rules.
On Sun, 22 Nov 2009 04:50:41 +0600, Mikhail Gusarov wrote: > Uhm. Now it eats much less :) > > $ make > ... > GZIPnotmuch.1.gz > /bin/sh: --rsyncable: not found > make: *** [notmuch.1.gz] Error 127 > $ > > $ make V=1 > ... > rsyncable --stdout notmuch.1 > notmuch.1.gz > /bin/sh: rsyncable: not found > make: [notmuch.1.gz] Error 127 (ignored) The bug here was in using the GZIP variable assuming it would be a program name. But since gzip expects it to be additional arguments, we need to use a different name such as a "gzip" variable. Thanks for the original implementation, Chris. And thanks for the testing, Mikhail. I've pushed the original plus the below on top. -Carl commit 1266d8511e9adc7296ec4ddbf609dec824b4c94f Author: Carl Worth Date: Sun Nov 22 04:45:16 2009 +0100 Makefile: Fix to work even with GZIP environment variable set. The rule here was written to assume that if the GZIP environment variable was set that it would be the gzip binary to execute, (similar to the CC and CXX variables). But GZIP is actually used to pass arguments to gzip, so we have to use a different name. diff --git a/Makefile b/Makefile index 5d8f321..ae8bff1 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,9 @@ CFLAGS=-O2 # Additional programs that are used during the compilation process. EMACS ?= emacs -GZIP ?= gzip +# Lowercase to avoid clash with GZIP environment variable for passing +# arguments to gzip. +gzip = gzip # Additional flags that we will append to whatever the user set. # These aren't intended for the user to manipulate. diff --git a/Makefile.local b/Makefile.local index 5fd5d4f..b6d3db3 100644 --- a/Makefile.local +++ b/Makefile.local @@ -23,7 +23,7 @@ notmuch: $(notmuch_client_modules) lib/notmuch.a $(call quiet,CXX) $^ $(LDFLAGS) -o $@ notmuch.1.gz: notmuch.1 - $(call quiet,GZIP) --stdout $^ > $@ + $(call quiet,gzip) --stdout $^ > $@ install: all notmuch.1.gz for d in $(DESTDIR)$(prefix)/bin/ $(DESTDIR)$(prefix)/share/man/man1 \
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sun, 22 Nov 2009 00:21:19 +0100, Jed Brown wrote: > On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth wrote: > > One thing we'll still have to think about is how to remove the "virtual > > tags" from the completion list, (once we have virtual tags in the > > configuration file---that is, tags applied automatically based on search > > specifications). > > Do these need to be real tags? Would it be sufficient for them to just > be aliases for search patterns? I think I would prefer the latter > because I could modify the pattern and not have to rewrite tags to the > whole database. Maybe real tags are needed to optimize expensive > patterns, but I wouldn't think the user needs to know about that. They are conceptually just aliases for search patterns, yes. But when I'm working with my mail I think I want them be accessible in an identical way to tags I apply manually. That is I want to be able to search for "tag:foo" and filter the current search view on the "bar" tag without having to remember to distinguish as a users whether "foo" or "bar" is a tag or an "aliased search term". As for your concerns, tag updates are going to be made really fast, (we just *have* to fix that bug, and soon), so I don't think there's going to be any problem with updating these rules and having to update the state in the database. -Carl
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
On Sun, 22 Nov 2009 00:25:43 +0100, Michiel Buddingh' wrote: > (hi, new here, just subscribed today. Wanted to reply to Carl's > earlier message I read in the archives, but since I don't have that, > I'm replying to Bart's reply to that message) Hi Michel, welcome to Notmuch! > Any attempt to match tags up to directories will eventually have > to deal with with the fact that tags can't be neatly mapped onto > them. If I remove a directory-tag from a message, does this > mean the message is removed from that directory? What if a > message has two directory-tags, does it mean it's present in both > directories? Right. We definitely don't want a strong mapping here. I think one answer could be that the initial import is different and can take the directory names as a "hint" for initializing tag values. After that, they are just tags in the database and the user can do whatever they want. This would mean that the user will need some other way to apply tags to future messages that might be delivered to those same directories. And we've got search-based tagging for that, (as well as manual tagging for the case where a user was manually filing messages into folders before). And while developing these search-based tags the user can use a different tag name. Say there was a directory named "foo", then the user might experiment with a search-based tag named "foo-search" and explore the results of things like: notmuch search tag:foo and not tag:foo-search notmuch search tag:foo-search and not tag:foo So even if in the end the user comes up with something that could replace the original tag, it's probably still beneficial to have it there when starting out. > At the same time, this kind of interoperability would be highly > desirable to those of us who access their mail using other > clients (webmail, mobile phones, etc.) that expect hierarchical > ordering. That kind of thing is going to be "harder". So far we're trying to stick with the principle that notmuch itself doesn't mess with the data store. But then, we also want notmuch to be very scriptable, so someone might write a tool that uses notmuch search to export a set of hierarchical maildirs based on the tag names. (These could even just be populated with symlinks like mairix does.) So something like that could be really useful for integrating. I'm very much of the opinion that the user shouldn't care at all about the storage of the actual mail files that notmuch indexes. > In the mean time, I've made a smaller, hopefully more harmless > patch to let 'notmuch new' mark messages stored in a Maildir 'cur' > folder as 'read' rather than 'unread'. Can others who have more experience weigh in here? Will this do the right thing for you? Do mail clients wait to move things into "cur" after the user has actually read them, or is that just a place where they are moved when the MUA _receives_ them? -Carl
[notmuch] [PATCH] Permit opening the notmuch database in read-only mode.
On Sat, 21 Nov 2009 20:08:31 +, Chris Wilson wrote: > [ickle: Updated to add WRITABLE mode to notmuch-new] Oops. I committed your earlier version, but then fixed this up afterwards myself. -Carl
[notmuch] RFC: Multiple filenames for email messages
On Sat, 21 Nov 2009 23:37:24 +0100, Jan Janak wrote: > The comment of _notmuch_message_set_filename says: > >XXX: We should still figure out if we think it's important to store >multiple filenames for email messages with identical message IDs. ... > I'd like to propose that we store all filenames for email messages in > the database, not just one per message. I'd be happy to work on it and > submit a patch if others think that this would be good to have. Oh, sure. As soon as we start using filenames for searches, then that makes a lot of sense. Currently, notmuch isn't storing any filename that way, but should be, (need to just add a prefix to the table at the top of lib/database.cc, document it, and then make the indexing stage generate terms from the filename with that prefix). The term generator and query parser should do the right thing, which is to split the filename into individual terms at each '/', store position data with each, and then turn a search like: filename:some/filename/segment into a phrase search that looks for the terms "some", "filename", and "segment", each with the filename prefix you choose and each in sequential position. Note that if you compile notmuch with CFLAGS including -DDEBUG then you'll see a nice report of the post-parsed query that's useful for debugging stuff like this. The reason for my comment was related to the other use of the filename, (that is, the only one we're currently using). This is with regard to querying the database for the actual filename, rather than searching on it. For this, we don't use terms, but instead use the "data" field of the document. I was wondering if in the presentation of an email message it would ever be important to have access to the multiple files. Can anyone think of a case where they would need that? That is, a case where you care about the distinct content of two messages that have the same message ID? I suppose that in the case of getting a message by two paths, (say through a mailing list and also via CC), one might want to inspect the different headers in the two versions. So maybe we'll need to break down and provide this information to the interfaces. Also, if we're going to support file deletion well, then I suppose we really will need to store all the filenames, (so if one disappears we can still point to the others). Also, we'll need to be able to accurately update the filename terms when a message disappears, so that means having all of the complete filenames around. So I guess I'm convincing myself that we really should store all the filenames, and also provide an interface to get a list of filenames for a message, (but also expect that many users of the API will only want to look at the first filename in the list). -Carl
[notmuch] suggestion/request about notmuch config
On Sat, 21 Nov 2009 18:06:38 -0500, Jameson Graef Rollins wrote: > Hi, folks. I just recently heard about notmuch and am very excited by > it. It looks like exactly what I've been waiting years for. Also > excited to see so much good development work happening. Hi Jamie, welcome to notmuch! > I would prefer to see all notmuch files and data in the same > directory, preferably: > > ~/.notmuch > > The config file could be: > > ~/.notmuch/config > > and the database could be: > > ~/.notmuch/db I suppose that's totally reasonable, (though I wouldn't abbreviate "database" to "db"). I think the only thing I'd miss is that I can currently point the config file to a different database, (which is usually just for testing.) And really, for that what I really want is a "-f" option to the notmuch command to make it read from a specified configuration file. So if I had that option then I don't think I'd mind this change at all. > Let me know what people think. Looking forward to working with > notmuch! And I'm looking forward to your contributions. Thanks again, -Carl
[notmuch] [PATCH] lib/database.cc: coding style
On Sat, 21 Nov 2009 23:14:39 +, Chris Wilson wrote: > Carl claims he must have been distracted when he wrote this... Indeed. Thanks for keeping my sloppy code looking so clean. -Carl
[notmuch] [PATCH] Mac OS X compatibility fixes
Hi Alex, On Sun, Nov 22, 2009 at 12:17 PM, Alexander Botero-Lowry wrote: >> +#ifdef __APPLE__ > Not awesome. > > This should be done in a capabilites way, for example strndup was added > to FreeBSD in 7.2 (which is this current release of the 7 line), and so > for older versions of FreeBSD strndup will be needed. getdelim() and > getline() came in FreeBSD 8, so they'll be needed for the entire 7 line. > So Instead of just assuming __APPLE__ this should be done by determing > if the symbols are generally needed. The problem is that notmuch does not have a fully functional configure process yet, Carl did mention Makefile.local, but it seems this file is not generated by configure right now. (No config.h either.) I will be happy to fix my patch if such facility (like AC_CHECK_FUNCS([getline])) exists. - Jiang
[notmuch] [PATCH 1/2] notmuch-new: Only install SIGALRM if not running under gdb
On Sun, 22 Nov 2009 00:44:31 +, Chris Wilson wrote: > I felt sorry for Carl trying to step through an exception from xapian > and suffering from the SIGALARMs.. You're too kind, Chris. These are both pushed. And did you notice the way I didn't push as soon as I found your patches in my inbox, but this time I looked for the *next* set of patches. ;-) -Carl
[notmuch] Guide for new users?
Hi, I think it will be nice if we can have a guide/tutorial like documentation for new users. For myself, I have the following questions (I am an alpine user previously, so some of the questions are not related to notmuch directly): 1. What's the most efficient way to sync mails from my gmail account to a local Maildir? I've tried offlineimap but it keeps crashing python (!) on my system (python 2.6, Mac OS X 10.6.2). 2. How to add notmuch.el into my .emacsrc? I know notmuch feels like a tool for geeks, but it will probably lower the barrier if someone can provide such a guide in a straightforward, step-by-step way. - Jiang
[notmuch] hijacked threads can be confusing in notmuch
On Sat, 21 Nov 2009 21:18:34 -0500, Bart Trojanowski wrote: > In mutt it looked like this: > > [notmuch] [PATCH 1/3] Make mouse-1 click in search view show thread > ??>[notmuch] [PATCH 2/3] Add 'notmuch count' command to show the count of > matching messages > ??>[notmuch] [PATCH 3/3] Add notmuch-index mode to display message counts > > ... and in the mutt threaded display the relationship between the three > messages is pretty clear. > > Now consider what happens when I run notmuch search 'notmuch count'. I > get this: > > Today 02:15 [2/3] Keith Packard; [notmuch] [PATCH 1/3] Make mouse-1 > click in search view show thread (inbox unread) Hmm... that's a bug. What notmuch *should* be doing here is taking as the subject of the thread the subject of the first message in the thread that matched, (rather than the subject of the first message in the thread). The thread_create has all that information, (it constructs two lists---one of all its messages, and one of matched messages). Now the next step is still missing. Let's say that instead of 2/3 mesages matched in the thread, (and by the way, did you all now that that's what's being reported there? it's not the number of unread messages or anything like that, but the number of matched messages). Anyway, let's say you had something like 1/20 there instead. And let's also assume that there aren't any unread messages in the thread. Then when you go to view that thread you will see all the messages open, and you won't have any information as to which message matched. What *should* happen here is that only the messages that matched should be open, and the messages that didn't match should be closed. Currently, the various pieces of the system don't have access to the information they need for this result. One way to do it would be to make "notmuch search" return a list of message IDs rather than a thread ID and then emacs could pass that list to "notmuch show". Alternately, the emacs interface could pass the current thread ID to "notmuch show" but also pass along the search string and then "notmuch show" could indicate which messages matched the search. Another thing to decide is how this relates with the default behavior of opening unread messages but closing read messages. Would possibility there could be to make that work just like any other search, just as I described above. If we were to go that route, I think it might mean getting rid of the distinction between "inbox" and "unread", and I'm not sure I want to do that or not. Anyway, I'd love to hear some ideas. > On a related note, one mail related pet peeve I have is when people > reply to a random email in their mailbox when they actually intend to > start a new thread. Doing that would totally mess up someone using > notmuch. They could get search results with threads which have no > relevance to their actual search... at least at first glance. Hopefully, the fix of displaying the subject from the first matched message would help here. -Carl
[notmuch] [PATCH] Fix invalid face reference.
To avoid the "Invalid face reference: cons [18 times]" kind of message goes on and on in the *Messages*. Signed-off-by: Kan-Ru Chen --- notmuch.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index 0144b61..a547415 100644 --- a/notmuch.el +++ b/notmuch.el @@ -553,7 +553,7 @@ which this thread was originally shown." (let ((beg (point-marker))) (end-of-line) ; Inverse video for subject -(overlay-put (make-overlay beg (point)) 'face '((cons :inverse-video t))) +(overlay-put (make-overlay beg (point)) 'face '(:inverse-video t)) (forward-line 2) (let ((beg-hidden (point-marker))) (re-search-forward notmuch-show-header-end-regexp) -- 1.6.5.3
[notmuch] [PATCH] Missing final semi-colon in .desktop's Categories.
Found the same problem on my own, only to minutes later catch up on the backlog of patches in my email and find this! On Sat, Nov 21, 2009 at 3:13 AM, James Rowe wrote: > "Those keys which have several values should have a semicolon as the trailing > character." > ?-- http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s03.html > > Signed-off-by: James Rowe Reviewed-by: Jeffrey C. Ollie > --- > ?notmuch.desktop | ? ?2 +- > ?1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/notmuch.desktop b/notmuch.desktop > index d29dff6..819cd1e 100644 > --- a/notmuch.desktop > +++ b/notmuch.desktop > @@ -4,4 +4,4 @@ Exec=emacs -f notmuch > ?Icon=emblem-mail > ?Terminal=false > ?Type=Application > -Categories=Network;Email > +Categories=Network;Email; > -- > 1.6.4.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch > -- Jeff Ollie
[notmuch] [PATCH] notmuch-show: Show message part using UTF-8.
Pass the message through the charset filter so that we can view
messages wrote in different charset encoding.
Signed-off-by: Kan-Ru Chen
---
notmuch-show.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index d727f30..c7f1320 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -72,12 +72,19 @@ show_part_content (GMimeObject *part)
GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
GMimeStream *stream_filter = NULL;
GMimeDataWrapper *wrapper;
+const char *charset;
+
+charset = g_mime_object_get_content_type_parameter (part, "charset");
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));
+if (charset) {
+ g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
+ g_mime_filter_charset_new(charset,
"UTF-8"));
+}
}
wrapper = g_mime_part_get_content_object (GMIME_PART (part));
--
1.6.5.3
[notmuch] 25 minutes load time with emacs -f notmuch
On Sat, Nov 21, 2009 at 05:36:18PM -0500, Brett Viren wrote: > On Sat, Nov 21, 2009 at 12:07 PM, Carl Worth wrote: > > > Though, frankly, I think we need to fix "notmuch new" to do much better > > than 40 files/sec. > > Just a "me too". > > Processed 130871 total files in 38m 7s (57 files/sec.). > Added 102723 new messages to the database (not much, really). > > This was ~2GB of mail on a 2.5GHz CPU. That seems pretty reasonable > to me but I'd like to rerun the "notmuch new" under google perftools > to see if there are any obvious bottlenecks that might be cleaned up. FWIW, my 90k+ messages mailbox was imported at a pace of 130 files/sec, and my CPU is "only" 2.2GHz, but I have a SSD. A good share of the bottlenecks is "simply" I/O. Don't forget having a lot of small files sucks I/O wise, as files are most likely spread all over the disk. A good test, if you have enough memory, would be to put your mailbox in a tmpfs, and see how fast that imports. Mike
[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode
This add two faces, notmuch-show-subject-face and
notmuch-tag-unread-face. The first face is used to show the subject
line in the notmuch-show-mode and the second one to show the unread
tag in the notmuch-search-mode. We can set additional tags by setting
notmuch-tag-face-alist as below
(defface notmuch-tag-unread-face
'class color) (background light)) (:foreground "goldenrod" :bold t))
(((class color) (background dark)) (:foreground "goldenrod" :bold t)))
"Notmuch search mode face used to highligh tags.")
(defface notmuch-tag-inbox-face
'class color) (background light)) (:foreground "red" :bold t))
(((class color) (background dark)) (:foreground "red" :bold t)))
"Notmuch search mode face used to highligh tags.")
(setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
("inbox" . 'notmuch-tag-inbox-face)))
(require 'notmuch)
Signed-off-by: Aneesh Kumar K.V
---
notmuch.el | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 0144b61..a0f5aaa 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -637,6 +637,18 @@ which this thread was originally shown."
(force-window-update)
(redisplay t))
+(defface notmuch-show-subject-face
+ 'class color) (background light)) (:foreground "yellow" :bold t))
+(((class color) (background dark)) (:foreground "yellow" :bold t)))
+ "Notmuch show mode face used to highligh subject line."
+ :group 'notmuch)
+
+(defvar notmuch-show-font-lock-keywords
+ (list ;; header in font-lock-type-face
+ (list "\\(Subject:.*$\\)"
+'(1 'notmuch-show-subject-face)))
+ "Additonal expression to hightlight in notmuch-show-mode")
+
;;;###autoload
(defun notmuch-show-mode ()
"Major mode for viewing a thread with notmuch.
@@ -677,7 +689,9 @@ 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)
+ (set (make-local-variable 'font-lock-defaults)
+ '(notmuch-show-font-lock-keywords t)))
;;;###autoload
@@ -806,6 +820,17 @@ thread from that buffer can be show when done with this
one)."
(goto-char (point-max))
(forward-line -1))
+(defface notmuch-tag-unread-face
+ 'class color) (background light)) (:foreground "goldenrod" :bold t))
+(((class color) (background dark)) (:foreground "goldenrod" :bold t)))
+ "Notmuch search mode face used to highligh tags."
+ :group 'notmuch)
+
+(defvar notmuch-tag-face-alist `(("unread" . 'notmuch-tag-unread-face))
+ "List containing the tag list that need to be highlighed")
+
+(defvar notmuch-search-font-lock-keywords nil)
+
;;;###autoload
(defun notmuch-search-mode ()
"Major mode for searching mail with notmuch.
@@ -836,7 +861,14 @@ global search.
(setq truncate-lines t)
(setq major-mode 'notmuch-search-mode
mode-name "notmuch-search")
- (setq buffer-read-only t))
+ (setq buffer-read-only t)
+ (setq notmuch-search-tags (mapcar 'car notmuch-tag-face-alist))
+ (loop for notmuch-search-tag in notmuch-search-tags
+do (add-to-list 'notmuch-search-font-lock-keywords (list
+ (concat "\\(" notmuch-search-tag "\\)")
+ `(1 ,(cdr (assoc notmuch-search-tag
notmuch-tag-face-alist))
+ (set (make-local-variable 'font-lock-defaults)
+ '(notmuch-search-font-lock-keywords t)))
(defun notmuch-search-find-thread-id ()
(save-excursion
--
1.6.5.2.74.g610f9
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
On Sun, 22 Nov 2009 05:04:56 +0100, Carl Worth wrote:
> Hi Michel, welcome to Notmuch!
Thanks, and apologies for the accidental base64 encoding.
First things first:
>> In the mean time, I've made a smaller, hopefully more harmless
>> patch to let 'notmuch new' mark messages stored in a Maildir 'cur'
>> folder as 'read' rather than 'unread'.
>
> Can others who have more experience weigh in here? Will this do the
> right thing for you? Do mail clients wait to move things into "cur"
> after the user has actually read them, or is that just a place where
> they are moved when the MUA _receives_ them?
You're absolutely right, and I'm a fool (because I _knew_ this, but
forgot). Maildir stores flags (seen, replied, flagged, trashed,
passed) in file names.
On the positive side, this allows us to map these flags onto tags,
at least for indexing (the patch at the bottom implements this), and,
if I can pry you away from your principles, later for modification
as well.
>> Any attempt to match tags up to directories will eventually have
>> to deal with with the fact that tags can't be neatly mapped onto
>> them. If I remove a directory-tag from a message, does this
>> mean the message is removed from that directory? What if a
>> message has two directory-tags, does it mean it's present in both
>> directories?
>
> Right. We definitely don't want a strong mapping here.
I propose that the maildir 'storage_type' could make an exception for
standard Maildir flags. It'll take relatively little effort to
special-case the abovementioned flags, and it'd be a huge boon to
interoperability.
>> At the same time, this kind of interoperability would be highly
>> desirable to those of us who access their mail using other
>> clients (webmail, mobile phones, etc.) that expect hierarchical
>> ordering.
>
> That kind of thing is going to be "harder".
>
> So far we're trying to stick with the principle that notmuch itself
> doesn't mess with the data store.
I respect your desire to stick to that principle. But I also know
that purity and simplicity, generally speaking, are unattainable
luxuries for most applications that handle mail.
> But then, we also want notmuch to be
> very scriptable, so someone might write a tool that uses notmuch search
> to export a set of hierarchical maildirs based on the tag names. (These
> could even just be populated with symlinks like mairix does.) So
> something like that could be really useful for integrating.
That is a very interesting idea. On the other hand, interoperability
with Maildir mail stores is unlikely to be a corner case. The MTA is
probably going to deliver new mail to a Maildir, procmail understands it,
etc. I'd feel more comfortable relegating this integration to a
scripted glue layer if I knew for certain such a glue layer would be
up to the task.
> I'm very much of the opinion that the user shouldn't care at all about
> the storage of the actual mail files that notmuch indexes.
The user certainly shouldn't, but I'm not sure that notmuch can remain
as agnostic about the actual storage of messages as planned.
Another thing; notmuch currently indexes by message-id (or SHA-1 hash
if that is not present). Maildir, on the other hand, uses file names
as stable (when stripped of the parts trailing the colon) unique
(knock on wood) identifiers. A Maildir-aware notmuch could incorporate
this to be far more resistant to bulk mail moves done by other clients,
by using filename lookups to avoid accessing and parsing the mail
files themselves.
I should re-iterate that I'm new to notmuch, and it's obvious that I'm
trying to beat it into becoming something it was never intended to be;
on the other hand, I'd like people to chime in on this.
again via webmail,
Michiel Buddingh'
---
notmuch-client.h | 10 ++
notmuch-config.c | 33 +--
notmuch-new.c| 95
+++--
3 files changed, 124 insertions(+), 14 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..c39be06 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -69,12 +69,16 @@
#define STRNCMP_LITERAL(var, literal) \
strncmp ((var), (literal), sizeof (literal) - 1)
+enum storage_type { UNSET, NONE, MAILDIR };
+
typedef void (*add_files_callback_t) (notmuch_message_t *message);
typedef struct {
int ignore_read_only_directories;
int saw_read_only_directory;
+enum storage_type storage_type;
+
int total_files;
int processed_files;
int added_messages;
@@ -179,7 +183,13 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
const char *other_email[],
size_t length);
+enum storage_type
+notmuch_config_get_storage_type (notmuch_config_t *config);
+
notmuch_bool_t
debugger_is_active (void);
+
+
+
#endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..13bd341 100644
--- a/notmu
[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode
On Sun, 22 Nov 2009 14:07:56 +0530, "Aneesh Kumar K.V" wrote:
> This add two faces, notmuch-show-subject-face and
> notmuch-tag-unread-face. The first face is used to show the subject
> line in the notmuch-show-mode and the second one to show the unread
> tag in the notmuch-search-mode. We can set additional tags by setting
> notmuch-tag-face-alist as below
Hi Aneesh,
I've been meaning to follow-up with you on this since I did get it
working.
> (setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
>("inbox" . 'notmuch-tag-inbox-face)))
It's interesting to be able to highlight specific tags like this. But I
think that first I'd like to have a single 'notmuch-tag face to make it
easier to see all the tag names, since they're hard to see among the
subject. And then maybe after that have s 'notmuch-tag-important-face or
something. I'm guessing that just that much would cover most people's
needs, before needing to choose custom colors for each tag name.
> +(defface notmuch-show-subject-face
> + 'class color) (background light)) (:foreground "yellow" :bold t))
> +(((class color) (background dark)) (:foreground "yellow" :bold t)))
> + "Notmuch show mode face used to highligh subject line."
> + :group 'notmuch)
Color selection can be pretty difficult, and I don't think we're ever
all going to agree on things. But I can at least say that I can't read
yellow on white at all, (maybe yellow on black works out a bit better, I
don't know).
So I'd definitely like to hear people's ideas on what the presentation
should look like here.
First, the current reverse-video is definitely not something I really
like. That was just a placeholder since I didn't know how to configure
other faces, (and I needed _something_ to distinguish one message from
another).
Second, from the time I spent with sup, I found that it was hard for me
to read entire lines of bold text. So I think I'd rather just have the
header name ("Subject:", for example) in bold and the rest of the
subject not bold. Hmm... maybe we could use a "From:" at the beginning
of the one line summary.
Finally, for separating one message from the other, I think I'd really
just like a one-pixel line drawn between the last line of text of one
message and the first line of text of the next message. Does anybody
know how to achieve that?
Back to the patch, I think I'll be able to push it as soon as I can
apply it and still _see_ the subject lines. ;-)
-Carl
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
[quick reply to the text without looking at the patch yet] On Sun, 22 Nov 2009 10:33:53 +0100, Michiel Buddingh' wrote: > Thanks, and apologies for the accidental base64 encoding. Thanks for noticing. That would have been a tricky patch to reply to to comment on. > On the positive side, this allows us to map these flags onto tags, > at least for indexing (the patch at the bottom implements this), and, > if I can pry you away from your principles, later for modification > as well. Yes, we might end up doing this. We'll see. > I respect your desire to stick to that principle. But I also know > that purity and simplicity, generally speaking, are unattainable > luxuries for most applications that handle mail. Hehe. Thanks for the entertainment. You sound like someone who's already got some of the battle scars from trying to write mail-handling software. One is certainly forced to see an awful lot of awfully strange things. > Another thing; notmuch currently indexes by message-id (or SHA-1 hash > if that is not present). Maildir, on the other hand, uses file names > as stable (when stripped of the parts trailing the colon) unique > (knock on wood) identifiers. A Maildir-aware notmuch could incorporate > this to be far more resistant to bulk mail moves done by other clients, > by using filename lookups to avoid accessing and parsing the mail > files themselves. I don't think opening a file to read out a message ID will ever be a bottleneck. But yes, we could take advantage of the unique name if we insisted that the storage have it. Personally, I still regularly end up indexing stuff that's not in proper maildir format, (like just manually copying a mail file "foo" down into a directory that I know isn't being delivered to by any MDA but that I want notmuch to index.) Maybe that's just me, because I'm always bringing up little things for debugging, etc. But it is convenient at least. So I think I'd like to be careful to avoid notmuch ever *requiring* maildir storage. (But yes, it should obviously support maildir well since it's so common.) > I should re-iterate that I'm new to notmuch, and it's obvious that I'm > trying to beat it into becoming something it was never intended to be; Actually, I don't think that's true at all. Notmuch is definitely intended to become a lot more than it is right now. And if it's not making it easy for you to deal with mail the way you'd like to, then we definitely do want to look into expanding notmuch to be able to address that. > on the other hand, I'd like people to chime in on this. I've got the patch tagged to give a closer look at it later. Thanks again, -Carl
[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode
On Sun, Nov 22, 2009 at 01:02:21PM +0100, Carl Worth wrote:
> On Sun, 22 Nov 2009 14:07:56 +0530, "Aneesh Kumar K.V" linux.vnet.ibm.com> wrote:
> > This add two faces, notmuch-show-subject-face and
> > notmuch-tag-unread-face. The first face is used to show the subject
> > line in the notmuch-show-mode and the second one to show the unread
> > tag in the notmuch-search-mode. We can set additional tags by setting
> > notmuch-tag-face-alist as below
>
> Hi Aneesh,
>
> I've been meaning to follow-up with you on this since I did get it
> working.
>
> > (setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
> > ("inbox" . 'notmuch-tag-inbox-face)))
>
> It's interesting to be able to highlight specific tags like this. But I
> think that first I'd like to have a single 'notmuch-tag face to make it
> easier to see all the tag names, since they're hard to see among the
> subject. And then maybe after that have s 'notmuch-tag-important-face or
> something. I'm guessing that just that much would cover most people's
> needs, before needing to choose custom colors for each tag name.
The default search pattern for notmuch is inbox and unread right. So adding
both of them to the notmuch-tag-face-alist should color the tags properly.
>
> > +(defface notmuch-show-subject-face
> > + 'class color) (background light)) (:foreground "yellow" :bold t))
> > +(((class color) (background dark)) (:foreground "yellow" :bold t)))
> > + "Notmuch show mode face used to highligh subject line."
> > + :group 'notmuch)
>
> Color selection can be pretty difficult, and I don't think we're ever
> all going to agree on things. But I can at least say that I can't read
> yellow on white at all, (maybe yellow on black works out a bit better, I
> don't know).
>
> So I'd definitely like to hear people's ideas on what the presentation
> should look like here.
>
> First, the current reverse-video is definitely not something I really
> like. That was just a placeholder since I didn't know how to configure
> other faces, (and I needed _something_ to distinguish one message from
> another).
>
> Second, from the time I spent with sup, I found that it was hard for me
> to read entire lines of bold text. So I think I'd rather just have the
> header name ("Subject:", for example) in bold and the rest of the
> subject not bold. Hmm... maybe we could use a "From:" at the beginning
> of the one line summary.
>
> Finally, for separating one message from the other, I think I'd really
> just like a one-pixel line drawn between the last line of text of one
> message and the first line of text of the next message. Does anybody
> know how to achieve that?
>
> Back to the patch, I think I'll be able to push it as soon as I can
> apply it and still _see_ the subject lines. ;-)
One of the easy part with emacs is we can use customize-face and select
notmuch-show-subject-face to select what ever suites your configuration.
For me with black background i found yellow with bold to be nice.
-aneesh
[notmuch] interesting project!
Hi Carl, > "Carl" == Carl Worth writes: >> Anyhow, I'll study the notmuch code and see if there are some useful >> bits in my code that might make sense there, e.g., various dir scanning >> optimizations, see [2]. Carl> That sounds great. It's also good to have people with experience in Carl> this area join and help out. I'll look forward to any ideas or other Carl> contributions you will have. Thanks for the nice words! A small question: it seems that notmuch is avoiding the use of GLib directly (of course, it depend on it anyway through GMime); is this because of OOM-handling? It'd be nice if GLib could be used, it would make some things quite a bit easier. Best wishes, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb at djcbsoftware.nl w:www.djcbsoftware.nl pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
> "Carl" == Carl Worth writes: Carl> On Sun, 22 Nov 2009 00:25:43 +0100, Michiel Buddingh' Carl> wrote: Carl> Hi Michel, welcome to Notmuch! >> Any attempt to match tags up to directories will eventually have >> to deal with with the fact that tags can't be neatly mapped onto >> them. If I remove a directory-tag from a message, does this >> mean the message is removed from that directory? What if a >> message has two directory-tags, does it mean it's present in both >> directories? Carl> Right. We definitely don't want a strong mapping here. I think one Carl> answer could be that the initial import is different and can take the Carl> directory names as a "hint" for initializing tag values. After that, Carl> they are just tags in the database and the user can do whatever they Carl> want. In 'mu' I took a slightly different approach, by simply allowing for searches on the path to the message; ie., by adding the path as just another property of the message, just like subject: or from:. Now, the trouble with that the path of a message is not very stable -- people move messages around. In 'mu' this was handled by simply considering the moved message as a new one, and removing message from the database whose paths do not point to message anymore. This makes things quite robust against people moving things around or deleting them. Tags could be connected to the hopefully unique Maildir file name then. Carl> notmuch search tag:foo and not tag:foo-search Carl> notmuch search tag:foo-search and not tag:foo Carl> So even if in the end the user comes up with something that could Carl> replace the original tag, it's probably still beneficial to have it Carl> there when starting out. So, an alternative would be something like: notmuch search path:inbox But this requires notmuch to be able to update things when paths change. Best wishes, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb at djcbsoftware.nl w:www.djcbsoftware.nl pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Hi Michiel, > "Michiel" == Michiel Buddingh' writes: Michiel> Another thing; notmuch currently indexes by message-id (or SHA-1 Michiel> hash if that is not present). Maildir, on the other hand, uses Michiel> file names as stable (when stripped of the parts trailing the Michiel> colon) unique (knock on wood) identifiers. A Maildir-aware Michiel> notmuch could incorporate this to be far more resistant to bulk Michiel> mail moves done by other clients, by using filename lookups to Michiel> avoid accessing and parsing the mail files themselves. I think that is a good idea. Michiel> I should re-iterate that I'm new to notmuch, and it's obvious Michiel> that I'm trying to beat it into becoming something it was never Michiel> intended to be; on the other hand, I'd like people to chime in on Michiel> this. I'm new here too, so please be gentle as I learn how things work Michiel> + Michiel> +static void Michiel> +derive_tags_from_maildir_flags (notmuch_message_t *message, const char * Michiel> path) I see you don't handle the "N" -- is that deliberate? Also, a minor addition may to also allow for '!' instead of ':' as a separator, as that's the semi-official way to use Maildirs on (V)FAT filesystems (which don't allow for colons in filenames). Best wishes, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb at djcbsoftware.nl w:www.djcbsoftware.nl pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
[notmuch] [PATCH] Fix invalid face reference.
On Sun, 22 Nov 2009 14:40:59 +0800, Kan-Ru Chen wrote: > To avoid the "Invalid face reference: cons [18 times]" kind of message > goes on and on in the *Messages*. Thanks. This is pushed. And welcome to notmuch, Kan-Ru! I'll look forward to any possible contributions from you in the future. -Carl
[notmuch] [PATCH] Missing final semi-colon in .desktop's Categories.
On Sun, 22 Nov 2009 01:07:49 -0600, Jeffrey Ollie wrote: > Found the same problem on my own, only to minutes later catch up on > the backlog of patches in my email and find this! ... > > Signed-off-by: James Rowe > > Reviewed-by: Jeffrey C. Ollie Much thanks, James and Jeffrey! I always feel *much* more comfortable pushing a patch I haven't tested personally if someone else has reviewed it. -Carl
[notmuch] [PATCH] notmuch-new: Eliminate gcc warning caused by ino_cmp.
The function passed to scandir in the fourth argument takes two
const void* arguments. To eliminate the gcc warning about incompatible
types, we change ino_cmp to match this and then re-type the parameters
in the body of ino_cmp.
Signed-off-by: Jan Janak
---
notmuch-new.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..6db3d0f 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -75,9 +75,10 @@ add_files_print_progress (add_files_state_t *state)
fflush (stdout);
}
-static int ino_cmp(const struct dirent **a, const struct dirent **b)
+static int ino_cmp(const void *a, const void *b)
{
-return ((*a)->d_ino < (*b)->d_ino) ? -1 : 1;
+return ((*(const struct dirent**)a)->d_ino <
+ (*(const struct dirent**)b)->d_ino) ? -1 : 1;
}
/* Examine 'path' recursively as follows:
--
1.6.3.3
[notmuch] [PATCH] notmuch-show: Show message part using UTF-8.
On Sun, 22 Nov 2009 16:30:47 +0800, Kan-Ru Chen wrote: > Pass the message through the charset filter so that we can view > messages wrote in different charset encoding. Thanks, very much. We definitely want notmuch to be presenting utf-8 only to the user. And I didn't realize I'd missed a part of this. Pushed. -Carl
[notmuch] [PATCH] makefile: Tell echo to interpret escape sequences.
The initial message that informs the user about the possibility to use make V=1 contains a \n at the end, but echo wouldn't interpret that properly without the -e command line option. --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index ae8bff1..3553ff4 100644 --- a/Makefile +++ b/Makefile @@ -41,7 +41,7 @@ include Makefile.config # user how to enable verbose compiles. ifeq ($(V),) quiet_DOC := "Use \"$(MAKE) V=1\" to see the verbose compile lines.\n" -quiet = @echo $(quiet_DOC)$(eval quiet_DOC:=)" $1 $@"; $($1) +quiet = @echo -e $(quiet_DOC)$(eval quiet_DOC:=)" $1 $@"; $($1) endif # The user has explicitly enabled quiet compilation. ifeq ($(V),0) -- 1.6.3.3
[notmuch] [PATCH] makefile: Declare clean target as phony.
This ensures that make clean always proceeds, even if the user accidentally creates a file named 'clean'. Also, it ignores errors in rm and other commands. Signed-off-by: Jan Janak --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 3553ff4..2d19a6e 100644 --- a/Makefile +++ b/Makefile @@ -75,5 +75,6 @@ DEPS := $(SRCS:%.c=.deps/%.d) DEPS := $(DEPS:%.cc=.deps/%.d) -include $(DEPS) +.PHONY : clean clean: rm -f $(CLEAN); rm -rf .deps -- 1.6.3.3
[notmuch] [PATCH] Add SCons build files.
The SCons build files included here *should* do everything that the
current Makefiles do, plus a little bit of configuration checking. To
build/install:
scons all emacs
sudo scons install
sudo scons install-emacs
sudo scons install-desktop
Various installation directories can be customized:
sudo scons install DESTDIR=/tmp/buildroot prefix=/opt/notmuch
See the output of 'scons -h' for a complete list of the variables that
can be modified.
Signed-off-by: Jeffrey C. Ollie
---
.gitignore |3 +
SConstruct | 226
lib/SConscript | 19 +
3 files changed, 248 insertions(+), 0 deletions(-)
create mode 100644 SConstruct
create mode 100644 lib/SConscript
diff --git a/.gitignore b/.gitignore
index 8794354..6661b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,6 @@ notmuch.1.gz
*~
.*.swp
*.elc
+.sconsign.dblite
+.sconf_temp
+config.log
diff --git a/SConstruct b/SConstruct
new file mode 100644
index 000..8d6960d
--- /dev/null
+++ b/SConstruct
@@ -0,0 +1,226 @@
+# -*- mode: python; coding: utf-8 -*-
+
+import os
+
+variables = Variables('custom.py')
+
+variables.Add('DESTDIR',
+ 'Destination directory',
+ '')
+
+variables.Add('prefix',
+ 'Installation prefix',
+ '/usr/local')
+
+variables.Add('bindir',
+ 'Directory that user binaries go into',
+ '${prefix}/bin')
+
+variables.Add('datadir',
+ 'Directory that static data files go into',
+ '${prefix}/share')
+
+variables.Add('mandir',
+ 'Directory that manual pages go into',
+ '${datadir}/man')
+
+variables.Add('emacs_lispdir',
+ 'Directory that Emacs LISP files go into',
+ '${default_emacs_lispdir}')
+
+variables.Add('sysconfdir',
+ 'Directory that system configuration files go into',
+ '/etc')
+
+variables.Add('bash_completion_dir',
+ 'Directory that Bash completion files go into',
+ '${sysconfdir}/bash_completion.d')
+
+variables.Add('desktop_dir',
+ 'Directory that desktop files go into',
+ '${datadir}/applications')
+
+variables.Add('gzip',
+ 'Gzip executable',
+ 'gzip')
+
+variables.Add('emacs',
+ 'Emacs executable',
+ 'emacs')
+
+def InstallPerm(env, dest, files, perm):
+obj = env.Install(dest, files)
+for i in obj:
+env.AddPostAction(i, Chmod(str(i), perm))
+return dest
+
+def InstallAsPerm(env, dest, files, perm):
+obj = env.InstallAs(dest, files)
+for i in obj:
+env.AddPostAction(i, Chmod(str(i), perm))
+return dest
+
+topenv = Environment(variables = variables,
+ BUILDERS = {'InstallPerm': InstallPerm,
+ 'InstallAsPerm': InstallAsPerm})
+
+topenv.Append(CPPPATH=['#/lib'])
+
+cflags = None
+if os.environ.has_key('CFLAGS'):
+cflags = topenv.ParseFlags(os.environ['CFLAGS'])
+topenv.MergeFlags(cflags)
+
+if os.environ.has_key('CXXFLAGS'):
+cxxflags = topenv.ParseFlags(os.environ['CXXFLAGS'])
+topenv.MergeFlags(cxxflags)
+
+if cflags is None or cxxflags is None:
+optflags = topenv.ParseFlags('-O2')
+topenv.MergeFlags(optflags)
+
+warnflags = topenv.ParseFlags('-Wall -Wextra -Wmissing-declarations
-Wwrite-strings -Wswitch-enum')
+topenv.MergeFlags(warnflags)
+
+def CheckPkgConfig(context, version):
+context.Message('Checking for pkg-config... ')
+result = context.TryAction('pkg-config --atleast-pkgconfig-version=%s' %
version)[0]
+context.Result(result)
+return result
+
+def CheckPkg(context, name):
+context.Message('Checking for %s... ' % name)
+result = context.TryAction('pkg-config --exists \'%s\'' % name)[0]
+context.Result(result)
+return result
+
+def CheckXapian(context):
+context.Message('Checking for xapian-core... ')
+for xapian_config in ['xapian-config-1.1', 'xapian-config']:
+result, output = context.TryAction('%s --version > $TARGET' %
xapian_config)
+if result:
+xapian_version = output.strip().split()[-1]
+context.env['xapian_config'] = xapian_config
+context.env['xapian_version'] = xapian_version
+context.Result(xapian_version)
+return result
+context.Result(False)
+return False
+
+def CheckEmacs(context):
+context.Message('Checking for emacs... ')
+context.env['default_emacs_lispdir'] = '${prefix}/share/emacs/site-lisp'
+result = context.TryAction('pkg-config --exists emacs')
+if result:
+result, output = context.TryAction('pkg-config emacs --variable
sitepkglispdir > $TARGET')
+if result:
+context.env['default_emacs_lispdir'] = output.strip()
+context.Result(True)
+return True
+context.Result(False)
+return False
+
+def CheckDesktopFileInstall(context):
+context.
[notmuch] [PATCH] Add SCons build files.
* Jeffrey C. Ollie [091122 08:47]: > The SCons build files included here *should* do everything that the > current Makefiles do, plus a little bit of configuration checking. To > build/install: Wouldn't that have the unfortunate side effect of making notmuch unusable w/o emacs and scons installed? GNU make has a much wider install base, and notmuch is still very useful without emacs. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] Guide for new users?
On Sat, Nov 21, 2009 at 11:44 PM, Jjgod Jiang wrote: > 1. What's the most efficient way to sync mails from my gmail > account to a local Maildir? I've tried offlineimap but it > keeps crashing python (!) on my system (python 2.6, Mac OS X > 10.6.2). OfflineIMAP would have been my suggestion. > 2. How to add notmuch.el into my .emacsrc? > > I know notmuch feels like a tool for geeks, but it will probably > lower the barrier if someone can provide such a guide in a > straightforward, step-by-step way. I put notmuch.el in an ~/.emacs.d/ directory. Then add this to your .emacs file: (add-to-list 'load-path (expand-file-name "~/.emacs.d")) (require 'notmuch) In the session type "M-x notmuch". -Brett.
[notmuch] [PATCH] fix compiler warnings
(hopefully this is the correct way to send patches...)
With these minor changes, notmuch compiles warning-free with gcc 4.4.1
---
notmuch-new.c |4 +++-
notmuch-setup.c | 13 +++--
notmuch-tag.c |4 +++-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..88b48a6 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -36,7 +36,9 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+if (write(2, msg, sizeof(msg)-1) < 0) {
+ /* ignore...*/
+}
interrupted = 1;
}
diff --git a/notmuch-setup.c b/notmuch-setup.c
index 482efd2..0d3f186 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -99,12 +99,13 @@ notmuch_setup_command (unused (void *ctx),
unsigned int i;
int is_new;
-#define prompt(format, ...)\
-do { \
- printf (format, ##__VA_ARGS__); \
- fflush (stdout);\
- getline (&response, &response_size, stdin); \
- chomp_newline (response); \
+#define prompt(format, ...)\
+do { \
+ printf (format, ##__VA_ARGS__); \
+ fflush (stdout);\
+ if (getline (&response, &response_size, stdin) < 0) \
+ break; \
+ chomp_newline (response); \
} while (0)
config = notmuch_config_open (ctx, NULL, &is_new);
diff --git a/notmuch-tag.c b/notmuch-tag.c
index e2311f6..5e40f50 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,9 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+if (write(2, msg, sizeof(msg)-1) < 0) {
+ /* ignore... */
+}
interrupted = 1;
}
--
1.6.3.3
[notmuch] 25 minutes load time with emacs -f notmuch
On Sun, Nov 22, 2009 at 3:36 AM, Mike Hommey wrote: > A good test, if you have enough memory, would be to put your mailbox in > a tmpfs, and see how fast that imports. (Oops, forgot to reply to the list.) I don't see any function calls related to I/O on the call graph. But, here is one that looks I/O bound: notmuch tag -unread tag:inbox I have my home directory on an encfs volume and I see it and notmuch competing for CPU when viewing "top". -Brett.
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Carl Worth wrote: > > A Maildir-aware notmuch could incorporate this to be far more > > resistant to bulk mail moves done by other clients, by using > > filename lookups to avoid accessing and parsing the mail > > files themselves. > I don't think opening a file to read out a message ID will ever be > a bottleneck. But yes, we could take advantage of the unique name > if we insisted that the storage have it. I'm not so sure. On traditional unix-like filesystems, every file access is another potential disk seek. People use a lot of different strategies for keeping their mail accessible and performant; you yourself, I gather, use non-semantic directories mainly intended to keep the number of files per directory low; others store their mail per month, or per year. I might choose to move all my mail from 2008 from my INBOX to the folder Archive.2008; such moves may change the paths of thousands of messages at a time. > Personally, I still regularly end up indexing stuff that's not > in proper maildir format, (like just manually copying a mail > file "foo" down into a directory that I know isn't being delivered > to by any MDA but that I want notmuch to index.) Maybe that's just > me, because I'm always bringing up little things for debugging, > etc. But it is convenient at least. Oh true. And it occurs to me that notmuch is a quite sensible companion tool to MH users (if they're still around in any numbers) > Actually, I don't think that's true at all. Notmuch is definitely > intended to become a lot more than it is right now. And if it's not > making it easy for you to deal with mail the way you'd like to, then > we definitely do want to look into expanding notmuch to be able to > address that. Thanks for your consideration; on the other hand, I do think that it is a good idea not to make matters more complex than they need to be, so I can certainly sympathise with the principles you've set for this project. regards, Michiel Buddingh'
[notmuch] [PATCH] Add SCons build files.
The SCons build files are not meant to require emacs. If I've messed something up and emacs is somehow required I would consider that a bug and would try to fix it. As far as availability, I'm sure that SCons is one yum or apt-get or away. The only people that would face more than a minor inconvenience are people that prefer to download tarballs and compile and install things themselves. Yes, I'm sure that make is widely available, but as notmuch gets used on a wider variety of systems some sort of configuration system will become necessary. If I can prevent another project from going down the autoconf/automake path I'll be happy. I started creating CMake build files but I don't know CMake well enough to come up with a working build. On 11/22/09, Bart Trojanowski wrote: > * Jeffrey C. Ollie [091122 08:47]: >> The SCons build files included here *should* do everything that the >> current Makefiles do, plus a little bit of configuration checking. To >> build/install: > > Wouldn't that have the unfortunate side effect of making notmuch > unusable w/o emacs and scons installed? > > GNU make has a much wider install base, and notmuch is still very useful > without emacs. > > -Bart > > -- > WebSig: http://www.jukie.net/~bart/sig/ > -- Sent from my mobile device Jeff Ollie
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Dirk-Jan C. Binnema wrote: > Michiel> + > Michiel> +static void > Michiel> +derive_tags_from_maildir_flags (notmuch_message_t > Michiel> *message, const char * > Michiel> path) > > I see you don't handle the "N" -- is that deliberate? Also, a > minor addition may to also allow for '!' instead of ':' as a > separator, as that's the semi-official way to use Maildirs on > (V)FAT filesystems (which don't allow for colons in filenames). Not deliberate. Simply unaware of the "N" flag, nor aware of practices for storing Maildirs on (V)FAT. I've used only this file as a reference. http://cr.yp.to/proto/maildir.html mvg, Michiel Buddingh'
[notmuch] [RFC PATCH] notmuch: Add support for multiple maildirs
This patch separate database path and maildir paths.
It also adds support for multiple maildir paths which
is represented by comma separated values. You need
to have in ~/.notmuch-config
[maildirs]
path=path1,path2
Signed-off-by: Aneesh Kumar K.V
---
notmuch-client.h |8
notmuch-config.c | 43 +++
notmuch-new.c| 24 +---
3 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..128fd7f 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -83,6 +83,11 @@ typedef struct {
add_files_callback_t callback;
} add_files_state_t;
+struct count_ele {
+ int count;
+ char ele[0];
+};
+
static inline void
chomp_newline (char *str)
{
@@ -182,4 +187,7 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
notmuch_bool_t
debugger_is_active (void);
+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config);
+
#endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..12b0081 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -62,6 +62,7 @@ struct _notmuch_config {
char *user_primary_email;
char **user_other_email;
size_t user_other_email_length;
+struct count_ele *maildirs;
};
static int
@@ -334,6 +335,48 @@ notmuch_config_get_database_path (notmuch_config_t *config)
return config->database_path;
}
+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config)
+{
+ int size;
+ char *cur_ptr;
+ char *dirs, *token, *saveptr;
+ struct count_ele *maildirs = NULL;
+ if (config->maildirs == NULL) {
+dirs = g_key_file_get_string (config->key_file,
+"maildirs", "path", NULL);
+ if (dirs) {
+ size = sizeof(struct count_ele) + strlen(dirs) + 1;
+ /* comma separated paths */
+ maildirs = (struct count_ele *)malloc(size);
+ maildirs->count = 0;
+ cur_ptr = maildirs->ele;
+ token = strtok_r(dirs, ",", &saveptr);
+ if (token == NULL) {
+ /* only one element */
+ strcpy(maildirs->ele, dirs);
+ maildirs->count = 1;
+ free(dirs);
+ config->maildirs = maildirs;
+ return maildirs;
+ }
+ strcpy(maildirs->ele, token);
+ maildirs->count++;
+ cur_ptr += strlen(token) + 1;
+ while ((token = strtok_r(NULL, ",", &saveptr))) {
+ strcpy(cur_ptr, token);
+ maildirs->count++;
+ cur_ptr += strlen(token) + 1;
+ }
+ free (dirs);
+ }
+ config->maildirs = maildirs;
+ }
+ return config->maildirs;
+
+
+}
+
void
notmuch_config_set_database_path (notmuch_config_t *config,
const char *database_path)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..1a9406b 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -385,14 +385,16 @@ notmuch_new_command (void *ctx,
{
notmuch_config_t *config;
notmuch_database_t *notmuch;
+const struct count_ele *maildirs;
add_files_state_t add_files_state;
double elapsed;
struct timeval tv_now;
-int ret = 0;
+int ret = 0, maildirs_count;
struct stat st;
const char *db_path;
char *dot_notmuch_path;
struct sigaction action;
+const char *maildir_path;
/* Setup our handler for SIGINT */
memset (&action, 0, sizeof (struct sigaction));
@@ -406,6 +408,9 @@ notmuch_new_command (void *ctx,
return 1;
db_path = notmuch_config_get_database_path (config);
+maildirs = notmuch_config_get_maildirs (config);
+if (maildirs == NULL)
+ return 1;
dot_notmuch_path = talloc_asprintf (ctx, "%s/%s", db_path, ".notmuch");
@@ -413,7 +418,13 @@ notmuch_new_command (void *ctx,
int count;
count = 0;
- count_files (db_path, &count);
+ maildirs_count = maildirs->count;
+ maildir_path = maildirs->ele;
+ while (maildirs_count) {
+ count_files (maildir_path, &count);
+ maildir_path += strlen(maildir_path) + 1;
+ maildirs_count--;
+ }
if (interrupted)
return 1;
@@ -439,7 +450,14 @@ notmuch_new_command (void *ctx,
add_files_state.added_messages = 0;
gettimeofday (&add_files_state.tv_start, NULL);
-ret = add_files (notmuch, db_path, &add_files_state);
+maildirs_count = maildirs->count;
+maildir_path = maildirs->ele;
+while
[notmuch] [PATCH] fix notmuch-new bug when database path ends with a trailing /
I configured my database.path with a trailing /, and after running notmuch
new every notmuch search would fail with error messages like this:
Error opening /inbox/cur/1258565257.000211.mbox:2,S: No such file or directory
The actual bug was in the filename normalization for storage in the
database. The database.path was removed from the full filename, but if
the database.path from the config file contained a trailing /, the
relative file name would retain an extra leading /... which made it look
like an absolute path after it was read out from the DB.
Signed-off-by: Bart Trojanowski
---
lib/message.cc | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 017c47b..1e325e2 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -411,10 +411,14 @@ _notmuch_message_set_filename (notmuch_message_t *message,
db_path = notmuch_database_get_path (message->notmuch);
db_path_len = strlen (db_path);
-if (*s == '/' && strncmp (s, db_path, db_path_len) == 0
- && strlen (s) > db_path_len)
+if (*s == '/' && strlen (s) > db_path_len
+ && strncmp (s, db_path, db_path_len) == 0)
{
- s += db_path_len + 1;
+ s += db_path_len;
+ while (*s == '/') s++;
+
+ if (!*s)
+ INTERNAL_ERROR ("Message filename was same as db prefix.");
}
message->doc.set_data (s);
--
1.6.4.4.2.gc2f148
[notmuch] Guide for new users?
On Sun, 22 Nov 2009 09:41:16 -0500, Brett Viren
wrote:
> On Sat, Nov 21, 2009 at 11:44 PM, Jjgod Jiang wrote:
>
> > 1. What's the most efficient way to sync mails from my gmail
> > account to a local Maildir? I've tried offlineimap but it
> > keeps crashing python (!) on my system (python 2.6, Mac OS X
> > 10.6.2).
>
> OfflineIMAP would have been my suggestion.
Yes, however it will change flags which changes file names and currently
confuses notmuch. I synced [Gmail].All Mail with OfflineIMAP and am now
using Getmail to pull via POP. In the Gmail settings, activate POP
starting at the current time. I'll switch back to OfflineIMAP when
notmuch is happy with changing file names.
The following should save notmuch + Gmail users some time.
~/.getmail/gmail:
[retriever]
# Getmail can also do IMAP
# type = SimpleIMAPSSLRetriever
# server = imap.gmail.com
type = SimplePOP3SSLRetriever
server = pop.gmail.com
username = yourname at gmail.com
password = Pa55W0rd
# Use this with IMAP to only download one copy of each message
# mailboxes = ('[Gmail]/All Mail',)
[destination]
type = Maildir
path = ~/.mail-archive/gmail/pop/
[options]
# print messages about each action (verbose = 2)
# Other options:
# 0 prints only warnings and errors
# 1 prints messages about retrieving and deleting messages only
verbose = 2
message_log = ~/.getmail/gmail.log
With getmail, put something like this in your crontab (checks every 2
minutes)
# MIN HOUR DAY MONTH DAYOFWEEK COMMAND
*/2 * * * * getmail -r gmail && notmuch new
~/.offlineimaprc:
[general]
accounts = GMail
maxsyncaccounts = 1
ui = Noninteractive.Basic
[Account GMail]
localrepository = Local
remoterepository = Remote
autorefresh = 1
quick = 10
postsynchook = notmuch new
[Repository Local]
type = Maildir
localfolders = /home/jed/.mail-archive/gmail/imap
[Repository Remote]
type = Gmail
folderfilter = lambda foldername: foldername in ['[Gmail]/All Mail']
remotehost = imap.gmail.com
remoteuser = yourname at gmail.com
remotepass = Pa55W0rd
ssl = yes
maxconnections = 2
#Setting realdelete = yes will Really Delete email from the server.
#Otherwise "deleting" a message will just remove any labels and
#retain the message in the All Mail folder.
realdelete = no
Note that with IMAP, your messages in '[Gmail]/All Mail' will be
delivered to a path with spaces which notmuch handles fine, but you will
need a patch
<1258771074-25997-1-git-send-email-jed at 59A2.org>
for start-process-shell-command, e.g. to apply patches from within emacs via
| git am
* Sending messages
To send messages from Emacs via Gmail, put something like this in your ~/.emacs
(setq smtpmail-starttls-credentials '(("smtp.gmail.com" 587 nil nil)) ; Must be
set BEFORE loading smtpmail
smtpmail-auth-credentials (expand-file-name "~/.authinfo")
smtpmail-default-smtp-server "smtp.gmail.com"
smtpmail-smtp-server "smtp.gmail.com"
smtpmail-smtp-service 587
smtpmail-debug-info t ; change to nil once it works
smtpmail-debug-verb t)
(require 'smtpmail)
(setq message-send-mail-function 'smtpmail-send-it)
(require 'starttls)
you can inline authentication, but especially if you keep ~/.emacs under
version control, you should put it separately (chmod 600).
~/.authinfo:
machine smtp.gmail.com login yourname at gmail.com password Pa55W0rd port 587
* Git
Git + Gmail users can use git send-email by putting this in your
.gitconfig
[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = yourname at gmail.com
smtppass = Pa55W0rd
I hope this helps.
Jed
[notmuch] [PATCH] Add SCons build files.
On Sun, 22 Nov 2009 10:00:26 -0600, Jeffrey Ollie wrote: > Yes, I'm sure that make is widely available, but as notmuch gets used > on a wider variety of systems some sort of configuration system will > become necessary. If I can prevent another project from going down > the autoconf/automake path I'll be happy. I started creating CMake > build files but I don't know CMake well enough to come up with a > working build. I can do a CMake build if that's desirable. While I prefer it to SCons, particularly when config/build times are an issue and you want to have several active build trees, it is a significantly heavier dependency. With SCons, you can dump scons-local (a pure Python script) into the source tree and then users only need Python. There are lots of other lightweight build tools. Jed
[notmuch] [RFC PATCH -V2] notmuch: Add support for multiple maildirs
This patch separate database path and maildir paths.
It also adds support for multiple maildir paths which
is represented by comma separated values. You need
to have in ~/.notmuch-config
[maildirs]
path=path1,path2
Signed-off-by: Aneesh Kumar K.V
---
notmuch-client.h | 12
notmuch-config.c | 54 ++
notmuch-new.c| 24 +---
notmuch-setup.c | 37 +++--
4 files changed, 122 insertions(+), 5 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..f2fc19f 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -83,6 +83,11 @@ typedef struct {
add_files_callback_t callback;
} add_files_state_t;
+struct count_ele {
+ int count;
+ char ele[0];
+};
+
static inline void
chomp_newline (char *str)
{
@@ -182,4 +187,11 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
notmuch_bool_t
debugger_is_active (void);
+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config);
+
+void
+notmuch_config_set_maildirs (notmuch_config_t *config,
+ const char *maildirs);
+
#endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..330da48 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -62,6 +62,7 @@ struct _notmuch_config {
char *user_primary_email;
char **user_other_email;
size_t user_other_email_length;
+struct count_ele *maildirs;
};
static int
@@ -345,6 +346,59 @@ notmuch_config_set_database_path (notmuch_config_t *config,
config->database_path = NULL;
}
+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config)
+{
+ int size;
+ char *cur_ptr;
+ char *dirs, *token, *saveptr;
+ struct count_ele *maildirs = NULL;
+ if (config->maildirs == NULL) {
+dirs = g_key_file_get_string (config->key_file,
+"maildirs", "path", NULL);
+ if (dirs) {
+ size = sizeof(struct count_ele) + strlen(dirs) + 1;
+ /* comma separated paths */
+ maildirs = (struct count_ele *)malloc(size);
+ maildirs->count = 0;
+ cur_ptr = maildirs->ele;
+ token = strtok_r(dirs, ",", &saveptr);
+ if (token == NULL) {
+ /* only one element */
+ strcpy(maildirs->ele, dirs);
+ maildirs->count = 1;
+ free(dirs);
+ config->maildirs = maildirs;
+ return maildirs;
+ }
+ strcpy(maildirs->ele, token);
+ maildirs->count++;
+ cur_ptr += strlen(token) + 1;
+ while ((token = strtok_r(NULL, ",", &saveptr))) {
+ strcpy(cur_ptr, token);
+ maildirs->count++;
+ cur_ptr += strlen(token) + 1;
+ }
+ free (dirs);
+ }
+ config->maildirs = maildirs;
+ }
+ return config->maildirs;
+
+
+}
+
+void
+notmuch_config_set_maildirs (notmuch_config_t *config,
+ const char *maildirs)
+{
+g_key_file_set_string (config->key_file,
+ "maildirs", "path", maildirs);
+
+free (config->maildirs);
+config->maildirs = NULL;
+}
+
const char *
notmuch_config_get_user_name (notmuch_config_t *config)
{
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..1a9406b 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -385,14 +385,16 @@ notmuch_new_command (void *ctx,
{
notmuch_config_t *config;
notmuch_database_t *notmuch;
+const struct count_ele *maildirs;
add_files_state_t add_files_state;
double elapsed;
struct timeval tv_now;
-int ret = 0;
+int ret = 0, maildirs_count;
struct stat st;
const char *db_path;
char *dot_notmuch_path;
struct sigaction action;
+const char *maildir_path;
/* Setup our handler for SIGINT */
memset (&action, 0, sizeof (struct sigaction));
@@ -406,6 +408,9 @@ notmuch_new_command (void *ctx,
return 1;
db_path = notmuch_config_get_database_path (config);
+maildirs = notmuch_config_get_maildirs (config);
+if (maildirs == NULL)
+ return 1;
dot_notmuch_path = talloc_asprintf (ctx, "%s/%s", db_path, ".notmuch");
@@ -413,7 +418,13 @@ notmuch_new_command (void *ctx,
int count;
count = 0;
- count_files (db_path, &count);
+ maildirs_count = maildirs->count;
+ maildir_path = maildirs->ele;
+ while (maildirs_count) {
+ count_files (maildir_path, &count);
+
[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.
Hello. On Sat, 2009-11-21 at 16:28, Keith Packard wrote: > On Sun, 22 Nov 2009 01:11:00 +0100, Stefan Schmidt datenfreihafen.org> wrote: > > > +const char * > > +notmuch_message_get_flags (notmuch_message_t *message) > > This function should interpret the flags that it finds and return a > suitable set of notmuch tags. I'd suggest that 'unread' messages get > both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between > 'don't show this to be by default again please' and 'I've read this > message'. It seems best to hide the maildir-specific details inside the > library instead of exposing them. Thanks for the review. On a second thought the interface was really a bit ugly. :) I'm just back to my box and going through the outstanding mails shows me that Michiel Buddingh has a more complete patch on the convert-maildir-flags-into-tags issue which Carl has tagged for review. Will wait what comes out of it and if anything is left for me to. :) regards Stefan Schmidt -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 250 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091122/3c68c8a9/attachment.pgp>
[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.
Stefan Schmidt wrote: > > This function should interpret the flags that it finds and return a > > suitable set of notmuch tags. I'd suggest that 'unread' messages get > > both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between > > 'don't show this to be by default again please' and 'I've read this > > message'. It seems best to hide the maildir-specific details inside the > > library instead of exposing them. > > Thanks for the review. On a second thought the interface was really a bit > ugly. > :) > > I'm just back to my box and going through the outstanding mails shows me that > Michiel Buddingh has a more complete patch on the > convert-maildir-flags-into-tags issue which Carl has tagged for review. Will > wait what comes out of it and if anything is left for me to. :) Apologies. In my haste to cover up my appalling and incorrect first patch, I neglected to review the archives to see if someone had already done this. Sorry for stealing your thunder. Michiel
[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.
Hello. On Sun, 2009-11-22 at 19:55, Michiel Buddingh' wrote: > Stefan Schmidt wrote: > > > This function should interpret the flags that it finds and return a > > > suitable set of notmuch tags. I'd suggest that 'unread' messages get > > > both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between > > > 'don't show this to be by default again please' and 'I've read this > > > message'. It seems best to hide the maildir-specific details inside the > > > library instead of exposing them. > > > > Thanks for the review. On a second thought the interface was really a bit > > ugly. > > :) > > > > I'm just back to my box and going through the outstanding mails shows me > > that > > Michiel Buddingh has a more complete patch on the > > convert-maildir-flags-into-tags issue which Carl has tagged for review. Will > > wait what comes out of it and if anything is left for me to. :) > > Apologies. In my haste to cover up my appalling and incorrect first patch, I > neglected to review the archives to see if someone had already done this. > Sorry > for stealing your thunder. No need to be sorry. I'm interestecd in having this itch scratched, but don't care who is doing it. :) Just go ahead and get it in after Carl's review. regards Stefan Schmidt
[notmuch] [PATCH] Add SCons build files.
On Sun, Nov 22, 2009 at 11:21 AM, Jed Brown wrote: > > I can do a CMake build if that's desirable. ?While I prefer it to SCons, > particularly when config/build times are an issue and you want to have > several active build trees, it is a significantly heavier dependency. > With SCons, you can dump scons-local (a pure Python script) into the > source tree and then users only need Python. ?There are lots of other > lightweight build tools. It would be interesting to compare SCons and CMake. CMake is probably more widely used since it's adoption by KDE but I like the fact that SCons build scripts are lightly camouflaged Python scripts. CMake's syntax has so far seemed to get in the way of me figuring out what I needed to do. While I prefer SCons, I wouldn't be unhappy if CMake was chosen. -- Jeff Ollie
[notmuch] [PATCH] New function notmuch-search-operate-all: operate on all messages in the current query.
It is often convenient to change tags on several messages at once. This function applies any number of tag whitespace-delimited tag modifications to all messages matching the current query. I have bound this to `*'. Signed-off-by: Jed Brown --- notmuch.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index a547415..b848e9a 100644 --- a/notmuch.el +++ b/notmuch.el @@ -764,6 +764,7 @@ thread from that buffer can be show when done with this one)." (define-key map (kbd "RET") 'notmuch-search-show-thread) (define-key map "+" 'notmuch-search-add-tag) (define-key map "-" 'notmuch-search-remove-tag) +(define-key map "*" 'notmuch-search-operate-all) (define-key map "<" 'beginning-of-buffer) (define-key map ">" 'notmuch-search-goto-last-thread) (define-key map "=" 'notmuch-search-refresh-view) @@ -940,6 +941,29 @@ This function advances point to the next line when finished." (notmuch-search-remove-tag "inbox") (forward-line)) +(defun notmuch-search-operate-all (action) + "Operate on all messages matching the current query. Any +number of whitespace separated actions can be given. Each action +must have one of the two forms + + +tagname Add the tag `tagname' + -tagname Remove the tag `tagname' + +Each character of the tag name may consist of alphanumeric +characters as well as `_.+-'. +" + (interactive "sOperation (+add -drop): notmuch tag ") + (let ((action-split (split-string action " +"))) +;; Perform some validation +(let ((words action-split)) + (when (null words) (error "No operation given")) + (while words + (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words)) + (error "Action must be of the form `+thistag -that_tag'")) + (setq words (cdr words +(apply 'notmuch-call-notmuch-process "tag" + (append action-split (list notmuch-search-query-string) nil + (defun notmuch-search (query &optional oldest-first) "Run \"notmuch search\" with the given query string and display results." (interactive "sNotmuch search: ") -- 1.6.5.3
[notmuch] How to index /var/spool/mail with notmuch
Hi all, I'd like to try out notmuch. My mail setup is as follows: - I run a local IMAP server (dovecot) and access it using Gnus - Dovecot stores its mails in /var/spool/mail/ in some one file per message format But I get some permission problems when trying to index /var/spool/mail. I was able to create a .notmuch/ directory in there with permissions set to 700 for my user. All mail files are readable for my user. Unfortunately, there are some dovecot internal files, which should neither be indexed by notmuch, and which have 600 permissions for the mail user. And that's where notmuch errors and stops indexing. :-( All "real" mail files are named "u.", so it would be cool if I could provide a pattern to notmuch matching all files I'd like to index. And maybe the other way round (a blacklist pattern) would be useful, too. Any thoughts? Maybe there's a better approach for what I'm trying to do? Bye, Tassilo
[notmuch] [PATCH] Add SCons build files.
My bad. I totally misread your introduction. * Jeffrey Ollie [091122 11:46]: > The SCons build files are not meant to require emacs. If I've messed > something up and emacs is somehow required I would consider that a bug > and would try to fix it. > > As far as availability, I'm sure that SCons is one yum or apt-get or > away. The only > people that would face more than a minor inconvenience are people that > prefer to download tarballs and compile and install things themselves. > > Yes, I'm sure that make is widely available, but as notmuch gets used > on a wider variety of systems some sort of configuration system will > become necessary. If I can prevent another project from going down > the autoconf/automake path I'll be happy. I started creating CMake > build files but I don't know CMake well enough to come up with a > working build. > > On 11/22/09, Bart Trojanowski wrote: > > * Jeffrey C. Ollie [091122 08:47]: > >> The SCons build files included here *should* do everything that the > >> current Makefiles do, plus a little bit of configuration checking. To > >> build/install: > > > > Wouldn't that have the unfortunate side effect of making notmuch > > unusable w/o emacs and scons installed? > > > > GNU make has a much wider install base, and notmuch is still very useful > > without emacs. > > > > -Bart > > > > -- > > WebSig: http://www.jukie.net/~bart/sig/ > > > > -- > Sent from my mobile device > > Jeff Ollie -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] [PATCH] Add SCons build files.
Personally I'd say we have better things to work on than maintaining multiple buildsystems for notmuch. Or than resolving possible packaging bugs originating in the use of different buildsystems. GNU has a very wide install bas, it's has a low footprint, and it happened to be the choice of the initial developers. All of this makes it the best choice imo. While I don't want to start a discussion on the merits of various buildsystems, I'll mention that, in my role as a packager, I'd choose just about anything over scons. My 2 cents, Ingmar -- Exherbo KDE, X.org maintainer
[notmuch] How to index /var/spool/mail with notmuch
On Sun, 22 Nov 2009 21:24:47 +0100, Tassilo Horn
wrote:
> Hi all,
>
> I'd like to try out notmuch. My mail setup is as follows:
>
> - I run a local IMAP server (dovecot) and access it using Gnus
> - Dovecot stores its mails in /var/spool/mail/ in some one file per
> message format
How about
$ mkdir -p ~/mail/spool
$ ln -s /var/spool/mail/$USER/{cur,new,tmp} ~/mail/spool
and point notmuch at ~/mail (or specifically ~/mail/spool).
Jed
[notmuch] How to index /var/spool/mail with notmuch
Jed Brown writes:
Hi Jed,
>> - I run a local IMAP server (dovecot) and access it using Gnus
>> - Dovecot stores its mails in /var/spool/mail/ in some one file per
>> message format
>
> How about
>
> $ mkdir -p ~/mail/spool
> $ ln -s /var/spool/mail/$USER/{cur,new,tmp} ~/mail/spool
>
> and point notmuch at ~/mail (or specifically ~/mail/spool).
Brilliant idea. :-)
Ok, now it's indexing my 63000 mails. 10 minutes to go.
Bye,
Tassilo
[notmuch] [PATCH] Add install target for desktop files.
Add an install target that uses desktop-file-install to install the desktop file in the appropriate location. The location of the install can be modified by changing the desktop_dir variable. Signed-off-by: Jeffrey C. Ollie --- Makefile.local |4 configure |1 + 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Makefile.local b/Makefile.local index c87e0c4..2e7c3cd 100644 --- a/Makefile.local +++ b/Makefile.local @@ -45,5 +45,9 @@ install-emacs: install emacs install -m0644 notmuch.el $(DESTDIR)$(emacs_lispdir) install -m0644 notmuch.elc $(DESTDIR)$(emacs_lispdir) +install-desktop: + install -d $(DESTDIR)$(desktop_dir) + desktop-file-install --mode 0644 --dir $(DESTDIR)$(desktop_dir) notmuch.desktop + SRCS := $(SRCS) $(notmuch_client_srcs) CLEAN := $(CLEAN) notmuch $(notmuch_client_modules) notmuch.elc notmuch.1.gz diff --git a/configure b/configure index b4770ec..1198ba7 100755 --- a/configure +++ b/configure @@ -132,5 +132,6 @@ EOF cat > Makefile.config <
[notmuch] [RFC] Precedence of OR and AND
Currently OR binds more weakly than AND, which is natural in most contexts, but I think it is rarely desirably for this sort of search. Suppose I am in looking at my inbox and decide to filter by term1 OR term2 Notmuch makes the query tag:inbox AND term1 OR term2 which is actually (tag:inbox AND term1) OR term2 and not at all what I wanted. Adding the necessary parentheses to notmuch-search-filter is trivial but it requires more parentheses for the overwhelming majority of searches that I think are more common. Are most searches indeed closer to conjunctive form? Should OR bind tighter than AND? Jed
[notmuch] [RFC] Precedence of OR and AND
Wouldn't this problem be solved by each filter appending a bracketed version of your filter? You start with tag:inbox and you filter on "term1 or term2" you'd get: tag:inbox and (term1 or term2) Doing it again would result in... tag:inbox and (term1 or term2) and (term3 or term4) To me, it would seem the most intuitive solution. Actually, I think I'll add that to notmuch.vim right now. :) -Bart * Jed Brown [091122 16:26]: > Currently OR binds more weakly than AND, which is natural in most > contexts, but I think it is rarely desirably for this sort of search. > Suppose I am in looking at my inbox and decide to filter by > > term1 OR term2 > > Notmuch makes the query > > tag:inbox AND term1 OR term2 > > which is actually > > (tag:inbox AND term1) OR term2 > > and not at all what I wanted. Adding the necessary parentheses to > notmuch-search-filter is trivial but it requires more parentheses for > the overwhelming majority of searches that I think are more common. > > Are most searches indeed closer to conjunctive form? > > Should OR bind tighter than AND? > > > Jed > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] [RFC] Precedence of OR and AND
On Sun, 22 Nov 2009 16:36:49 -0500, Bart Trojanowski wrote: > Wouldn't this problem be solved by each filter appending a bracketed > version of your filter? > > You start with tag:inbox and you filter on "term1 or term2" you'd get: > > tag:inbox and (term1 or term2) Absolutely, and I have this applied locally to notmuch.el, but I didn't fix notmuch-search-filter-by-tag because that would really need to parse the expression. I'm just asking if anyone else thinks binding OR tighter than AND would be desirable. Jed
[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Hi Michiel, > "MB" == Michiel Buddingh' writes: MB> Dirk-Jan C. Binnema wrote: Michiel> + Michiel> +static void Michiel> +derive_tags_from_maildir_flags (notmuch_message_t Michiel> *message, const char * Michiel> path) >> >> I see you don't handle the "N" -- is that deliberate? Also, a >> minor addition may to also allow for '!' instead of ':' as a >> separator, as that's the semi-official way to use Maildirs on >> (V)FAT filesystems (which don't allow for colons in filenames). MB> Not deliberate. Simply unaware of the "N" flag, nor aware of MB> practices for storing Maildirs on (V)FAT. Ah, you are right. In my code, http://gitorious.org/mu/mainline/blobs/master/msg/mu-msg-flags.c I handled it because apparently some programs where using that. But I guess it's better to stick to DJB's Maildir spec for now... Regarding the VFAT-limitations, see eg. the Note in: http://docs.python.org/lib/mailbox-maildir.html anyway, a minor point. Best wishes, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb at djcbsoftware.nl w:www.djcbsoftware.nl pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
[notmuch] [RFC] Precedence of OR and AND
* Jed Brown [091122 16:43]: > Absolutely, and I have this applied locally to notmuch.el, but I didn't > fix notmuch-search-filter-by-tag because that would really need to parse > the expression. I'm just asking if anyone else thinks binding OR > tighter than AND would be desirable. Maybe some of the ambiguity would go away if we used && and || instead of AND and OR. Then no matter the default, we could distinguish if someone meant 2 or 3 tags when they typed in 'foo and bar'. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] Catching up unread messages
Hi! I got notmuch running, and it's absolutely incredible. It's so damn fast and the results are very good. So thanks a lot for creating this nice piece of software. :-) Ok, so new the question: I indexed all my 63.000 mails, and because it was a first-time indexing, all my mail now has the tags inbox and unread. Of course, I don't want to SPC through all threads (using the great emacs interface) to remove the unread status. So is there some catchup command, which marks all messages in the buffer as read? BTW, what's the intention of the inbox tag? When I've read a thread, both inbox as well as unread disappear, so I don't get the difference between them. Bye, Tassilo
[notmuch] Catching up unread messages
* Tassilo Horn [091122 16:49]: > Ok, so new the question: I indexed all my 63.000 mails, and because it > was a first-time indexing, all my mail now has the tags inbox and > unread. Of course, I don't want to SPC through all threads (using the > great emacs interface) to remove the unread status. So is there some > catchup command, which marks all messages in the buffer as read? notmuch tag -unread -- tag:unread -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] Catching up unread messages
On Sun, 22 Nov 2009 22:48:52 +0100, Tassilo Horn wrote: > Ok, so new the question: I indexed all my 63.000 mails, and because it > was a first-time indexing, all my mail now has the tags inbox and > unread. Of course, I don't want to SPC through all threads (using the > great emacs interface) to remove the unread status. So is there some > catchup command, which marks all messages in the buffer as read? With this patch <1258920736-14205-1-git-send-email-jed at 59A2.org> you would do * -inbox or * -inbox -unread On the command line, you can clear it with $ notmuch tag -inbox tag:inbox > BTW, what's the intention of the inbox tag? When I've read a thread, > both inbox as well as unread disappear, so I don't get the difference > between them. That is because SPC is bound to notmuch-show-advance-marking-read-and-archiving which removes both tags. The idea is that you can clear your inbox while retaining unread status, or leave something important in your inbox even though you have read it. Jed
[notmuch] [PATCH 2/3] modify notmuch_setup_command to return 1 if config file write fails.
This fixes a small bug in notmuch_setup_command such that it returned
OK and output the setup message footer even if the config file write
step failed.
---
notmuch-setup.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/notmuch-setup.c b/notmuch-setup.c
index 482efd2..68788e1 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -155,10 +155,11 @@ notmuch_setup_command (unused (void *ctx),
notmuch_config_set_database_path (config, absolute_path);
}
-notmuch_config_save (config);
-
-if (is_new)
- welcome_message_post_setup ();
-
-return 0;
+if (! notmuch_config_save (config)) {
+ if (is_new)
+ welcome_message_post_setup ();
+ return 0;
+} else {
+ return 1;
+}
}
--
1.6.5
[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config
This change creates a ~/.notmuch config directory where the config
file is stored when created with the "setup" command. The use of a
~/.notmuch config directory creates one place where all notmuch config
files and data can be stored, which will greatly simplify managing
notmuch, and reduce cluter of user dot files.
---
notmuch-config.c | 21 ++---
notmuch-setup.c |2 +-
notmuch.1|4 ++--
notmuch.c|2 +-
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/notmuch-config.c b/notmuch-config.c
index 7252a19..321c880 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -22,9 +22,11 @@
#include
#include
+#include
+#include
static const char toplevel_config_comment[] =
-" .notmuch-config - Configuration file for the notmuch mail system\n"
+" .notmuch/config - Configuration file for the notmuch mail system\n"
"\n"
" For more information about notmuch, see http://notmuchmail.org";;
@@ -134,7 +136,7 @@ get_username_from_passwd_file (void *ctx)
/* Open the named notmuch configuration file. A filename of NULL will
* be interpreted as the default configuration file
- * ($HOME/.notmuch-config).
+ * ($HOME/.notmuch/config).
*
* If any error occurs, (out of memory, or a permission-denied error,
* etc.), this function will print a message to stderr and return
@@ -183,7 +185,7 @@ notmuch_config_open (void *ctx,
if (filename)
config->filename = talloc_strdup (config, filename);
else
- config->filename = talloc_asprintf (config, "%s/.notmuch-config",
+ config->filename = talloc_asprintf (config, "%s/.notmuch/config",
getenv ("HOME"));
config->key_file = g_key_file_new ();
@@ -297,14 +299,27 @@ notmuch_config_save (notmuch_config_t *config)
{
size_t length;
char *data;
+char buf[256];
GError *error = NULL;
+struct stat statbuf;
+
data = g_key_file_to_data (config->key_file, &length, NULL);
if (data == NULL) {
fprintf (stderr, "Out of memory.\n");
return 1;
}
+/* Create config directory if it doesn't already exist */
+snprintf(buf, sizeof buf, "%s", config->filename);
+dirname(buf);
+if (stat(buf, &statbuf) < 0) {
+ if (mkdir(buf, 0755) < 0) {
+ fprintf (stderr, "Could not create directory '%s'\n.", buf);
+ return 1;
+ }
+}
+
if (! g_file_set_contents (config->filename, data, length, &error)) {
fprintf (stderr, "Error saving configuration to %s: %s\n",
config->filename, error->message);
diff --git a/notmuch-setup.c b/notmuch-setup.c
index 68788e1..76e104c 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -74,7 +74,7 @@ welcome_message_post_setup (void)
{
printf ("\n"
"Notmuch is now configured, and the configuration settings are saved in\n"
-"a file in your home directory named .notmuch-config . If you'd like to\n"
+"a file in your home directory named .notmuch/config . If you'd like to\n"
"change the configuration in the future, you can either edit that file\n"
"directly or run \"notmuch setup\".\n\n"
diff --git a/notmuch.1 b/notmuch.1
index 8a3fb40..9ea1d42 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -53,7 +53,7 @@ Interactively sets up notmuch for first use.
The setup command will prompt for your full name, your primary email
address, any alternate email addresses you use, and the directory
containing your email archives. Your answers will be written to a
-configuration file in ${HOME}/.notmuch-config . This configuration
+configuration file in ${HOME}/.notmuch/config . This configuration
file will be created with descriptive comments, making it easy to edit
by hand later to change the configuration. Or you can run
.B "notmuch setup"
@@ -245,7 +245,7 @@ takes an existing set of messages and constructs a suitable
mail
template. The Reply-to header (if any, otherwise From:) is used for
the To: address. Vales from the To: and Cc: headers are copied, but
not including any of the current user's email addresses (as configured
-in primary_mail or other_email in the .notmuch-config file) in the
+in primary_mail or other_email in the .notmuch/config file) in the
recipient list
It also builds a suitable new subject, including Re: at the front (if
diff --git a/notmuch.c b/notmuch.c
index 5cc8e4c..2d19a91 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -98,7 +98,7 @@ command_t commands[] = {
"\t\tThe setup command will prompt for your full name, your primary\n"
"\t\temail address, any alternate email addresses you use, and the\n"
"\t\tdirectory containing your email archives. Your answers will be\n"
- "\t\twritten to a configuration file in ${HOME}/.notmuch-config .\n"
+ "\t\twritten to a configuration file in ${HOME}/.notmuch/config .\n"
"\n"
"\t\tThis configuration file will be created with descriptive\n"
"\t\tcomments, making it easy to edit by hand later to
[notmuch] [PATCH 1/3] remove Makefile.config from source to allow for custom config.
Modified ./configure script to generate a Makefile.config if it doesn't exist. This will allow people to maintain custom Makefile.config files without causing conflicts with the repository. --- Makefile.config |2 -- configure |8 2 files changed, 8 insertions(+), 2 deletions(-) delete mode 100644 Makefile.config diff --git a/Makefile.config b/Makefile.config deleted file mode 100644 index d72a39e..000 --- a/Makefile.config +++ /dev/null @@ -1,2 +0,0 @@ -prefix = /usr/local -bash_completion_dir = /etc/bash_completion.d diff --git a/configure b/configure index fe46c8e..c63f70d 100755 --- a/configure +++ b/configure @@ -109,6 +109,14 @@ configure again to ensure the packages can be found, or simply run EOF exit 1 else + +if [ ! -e Makefile.config ] ; then +cat
[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config
onfigured, and the configuration settings are saved in\n"
> -"a file in your home directory named .notmuch-config . If you'd like to\n"
> +"a file in your home directory named .notmuch/config . If you'd like to\n"
> "change the configuration in the future, you can either edit that file\n"
> "directly or run \"notmuch setup\".\n\n"
>
> diff --git a/notmuch.1 b/notmuch.1
> index 8a3fb40..9ea1d42 100644
> --- a/notmuch.1
> +++ b/notmuch.1
> @@ -53,7 +53,7 @@ Interactively sets up notmuch for first use.
> The setup command will prompt for your full name, your primary email
> address, any alternate email addresses you use, and the directory
> containing your email archives. Your answers will be written to a
> -configuration file in ${HOME}/.notmuch-config . This configuration
> +configuration file in ${HOME}/.notmuch/config . This configuration
> file will be created with descriptive comments, making it easy to edit
> by hand later to change the configuration. Or you can run
> .B "notmuch setup"
> @@ -245,7 +245,7 @@ takes an existing set of messages and constructs a
> suitable mail
> template. The Reply-to header (if any, otherwise From:) is used for
> the To: address. Vales from the To: and Cc: headers are copied, but
> not including any of the current user's email addresses (as configured
> -in primary_mail or other_email in the .notmuch-config file) in the
> +in primary_mail or other_email in the .notmuch/config file) in the
> recipient list
>
> It also builds a suitable new subject, including Re: at the front (if
> diff --git a/notmuch.c b/notmuch.c
> index 5cc8e4c..2d19a91 100644
> --- a/notmuch.c
> +++ b/notmuch.c
> @@ -98,7 +98,7 @@ command_t commands[] = {
>"\t\tThe setup command will prompt for your full name, your primary\n"
>"\t\temail address, any alternate email addresses you use, and the\n"
>"\t\tdirectory containing your email archives. Your answers will be\n"
> - "\t\twritten to a configuration file in ${HOME}/.notmuch-config .\n"
> + "\t\twritten to a configuration file in ${HOME}/.notmuch/config .\n"
>"\n"
>"\t\tThis configuration file will be created with descriptive\n"
>"\t\tcomments, making it easy to edit by hand later to change the\n"
> --
> 1.6.5
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/ee48dad6/attachment.pgp>
[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config
I totally agree with Jamie about the config rename. I don't know if I
agree with the database location change... but I might just need some
convincing.
Would it be enough to just read .notmuch/config and fall back to
.notmuch-config otherwise?
-Bart
* Jameson Graef Rollins [091122 17:15]:
> Hi, folks. I wanted to comment on this patch request.
>
> I personally think it makes a lot of sense to use config directories.
> This makes things much neater, since all config files can be kept in
> one place without clutter the config name space. I can imagine down
> the line that there may be more notmuch config files, and it would be
> nicer to have a config directory rather than a bunch of ~/.notmuch-*
> files in the user dot file config space.
>
> I also imagine this config directory as a place to store the notmuch
> database files. I would rather keep all the notmuch data and config
> files together in one place, and keep my mail directories completely
> untouched (only read) by notmuch, if possible.
>
> I realize, however, there is a transition problem associated with
> moving the config file, which is why I propose it be moved sooner
> rather than later. If folks are interested in this change, and are
> worried about transition even at this early stage, we can try to come
> up with some smoother transition code.
>
> Finally, I am (maybe clearly) *not* particularly adept at c
> programming. I'm still learning. I think I already have better ways
> to improve this patch. I will try to make some improvements and send
> those along as well.
>
> jamie.
>
> PS. I'm sure this has already been discussed on the list, but if this
> is not the best way to send patches, please let me know. I would be
> happy to send a pointer to my notmuch git repo if it would be
> preferable to just pull from it directly.
>
>
> On Sun, Nov 22, 2009 at 04:58:36PM -0500, Jameson Graef Rollins wrote:
> > This change creates a ~/.notmuch config directory where the config
> > file is stored when created with the "setup" command. The use of a
> > ~/.notmuch config directory creates one place where all notmuch config
> > files and data can be stored, which will greatly simplify managing
> > notmuch, and reduce cluter of user dot files.
> > ---
> > notmuch-config.c | 21 ++---
> > notmuch-setup.c |2 +-
> > notmuch.1|4 ++--
> > notmuch.c|2 +-
> > 4 files changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/notmuch-config.c b/notmuch-config.c
> > index 7252a19..321c880 100644
> > --- a/notmuch-config.c
> > +++ b/notmuch-config.c
> > @@ -22,9 +22,11 @@
> >
> > #include
> > #include
> > +#include
> > +#include
> >
> > static const char toplevel_config_comment[] =
> > -" .notmuch-config - Configuration file for the notmuch mail system\n"
> > +" .notmuch/config - Configuration file for the notmuch mail system\n"
> > "\n"
> > " For more information about notmuch, see http://notmuchmail.org";;
> >
> > @@ -134,7 +136,7 @@ get_username_from_passwd_file (void *ctx)
> >
> > /* Open the named notmuch configuration file. A filename of NULL will
> > * be interpreted as the default configuration file
> > - * ($HOME/.notmuch-config).
> > + * ($HOME/.notmuch/config).
> > *
> > * If any error occurs, (out of memory, or a permission-denied error,
> > * etc.), this function will print a message to stderr and return
> > @@ -183,7 +185,7 @@ notmuch_config_open (void *ctx,
> > if (filename)
> > config->filename = talloc_strdup (config, filename);
> > else
> > - config->filename = talloc_asprintf (config, "%s/.notmuch-config",
> > + config->filename = talloc_asprintf (config, "%s/.notmuch/config",
> > getenv ("HOME"));
> >
> > config->key_file = g_key_file_new ();
> > @@ -297,14 +299,27 @@ notmuch_config_save (notmuch_config_t *config)
> > {
> > size_t length;
> > char *data;
> > +char buf[256];
> > GError *error = NULL;
> >
> > +struct stat statbuf;
> > +
> > data = g_key_file_to_data (config->key_file, &length, NULL);
> > if (data == NULL) {
> > fprintf (stderr, "Out of memory.\n");
> > return 1;
> > }
> >
> > +/* Create config directory if it doesn't already exist */
> > +snprintf(buf, sizeof buf, "%s", config->filename);
> > +dirname(buf);
> > +if (stat(buf, &statbuf) < 0) {
> > + if (mkdir(buf, 0755) < 0) {
> > + fprintf (stderr, "Could not create directory '%s'\n.", buf);
> > + return 1;
> > + }
> > +}
> > +
> > if (! g_file_set_contents (config->filename, data, length, &error)) {
> > fprintf (stderr, "Error saving configuration to %s: %s\n",
> > config->filename, error->message);
> > diff --git a/notmuch-setup.c b/notmuch-setup.c
> > index 68788e1..76e104c 100644
> > --- a/notmuch-setup.c
> > +++ b/notmuch-setup.c
> > @@ -74,7 +74,7 @@ welcome_message_post_setup (void)
>
[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode
On Sun, 22 Nov 2009 17:51:06 +0530, "Aneesh Kumar K.V" wrote: > > It's interesting to be able to highlight specific tags like this. But I > > think that first I'd like to have a single 'notmuch-tag face to make it > > easier to see all the tag names, since they're hard to see among the > > subject. And then maybe after that have s 'notmuch-tag-important-face or > > something. I'm guessing that just that much would cover most people's > > needs, before needing to choose custom colors for each tag name. > > The default search pattern for notmuch is inbox and unread right. So adding > both of them to the notmuch-tag-face-alist should color the tags > properly. Well, actually the default search pattern for notmuch is just "inbox". But it's really about *all* the tags I have on the messages. I would like all of my tags to stand out from the subject line, (and I don't want to keep adjusting notmuch-tag-face-alist every time I add a new tag). I'd prefer instead to just be able to choose a color that would highlight everyhing between the final set of parentheses in the search results. > One of the easy part with emacs is we can use customize-face and select > notmuch-show-subject-face to select what ever suites your configuration. > For me with black background i found yellow with bold to be nice. OK. I'll experiment and look for a reasonable color for a white background. -Carl
[notmuch] interesting project!
On Sun, 22 Nov 2009 14:23:10 +0200, Dirk-Jan C. Binnema wrote: > A small question: it seems that notmuch is avoiding the use of GLib directly > (of course, it depend on it anyway through GMime); is this because of > OOM-handling? It'd be nice if GLib could be used, it would make some things > quite a bit easier. It's true that I don't like the OOM handling in glib. I also think that glib tries to be too many different things at the same time. And finally, having some talloc-friendly data structures (like a hash-table) would be really nice. In the meantime, as you say, we're already linking with glib because of GMime, so there's really no reason not to call functions that are there and that do what we want. What kinds of things were you thinking of that would be easier with glib? -Carl
[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config
On Sun, Nov 22, 2009 at 05:24:53PM -0500, Bart Trojanowski wrote: > I totally agree with Jamie about the config rename. I don't know if I > agree with the database location change... but I might just need some > convincing. So I don't really like having the database stored in the maildir. There are a couple reasons for this: - I would prefer to keep all notmuch stuff together, including all config files, data files, etc. In my opinion, this just makes things easier to keep track of. No need to guess where any relevant notmuch data is if it's all stored together in one place. - I would prefer to not clutter my mail directories with anything that's not mail. The notmuch database is definitely related to my mail, but it's not exactly my mail, so I'd rather keep it somewhere else. (I think there's a whole other thread to be started about this, because I think the config should also hold the location of the maildir to be indexed, not the path to the index itself, which then makes implicit assumptions about where the maildir is.) This point is also probably related to the fact that I've had to change MUAs too many times to trust one indefinitely. So basically I want to keep my mail wholly separate from anything that's processing it. I think Carl said he wanted to keep the ability to specify exactly where the database is stored, so if we could move away from something that makes any implicit assumptions about relative paths between the database and the maildir, then all should be ok. > Would it be enough to just read .notmuch/config and fall back to > .notmuch-config otherwise? Yes, this is a good idea. I'll try to come up with a patch for this. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091122/eb974930/attachment.pgp>
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Mon, 23 Nov 2009 00:19:29 +0100, Carl Worth wrote: > I'm starting to come around to this patch, Keith. :-) I'll keep posting it then :-) > I think one thing we're going to really need is a better help message > for presenting the keybindings. The function names are all really > confusing, (the "notmuch-show" prefix doesn't help). So what I'd really > like is something that displays the keybinding and the first line of the > documentation of a function, rather than the function name itself. That's a fine plan. It 'shouldn't' be too hard to implement either. Btw, I'm thinking that it might be useful to create some 'global' notmuch keybindings and then create per-view bindings that also expose the global bindings. That way, things like 'm' to create a new mail would work consistently in each view. Note that this idea is inconsistent with the following though... > Except that the patch also reverses the current behavior of "a" and > "A". That should be a separate patch anyway, but I'm also not sure that > I like it. I like that the command that takes the extra effort of > pressing shift is the command that does *more*, (removing both "unread" > and "inbox"), rather than the command that does *less*. I was trying to make the 'normal' action easier; for me, if I'm looking at a message, then the normal action is to mark it read and archived, but when I'm looking only at the subject line in the search window, the normal action is just to mark it archived (having not actually read the 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/20091122/bdbe4a5c/attachment.pgp>
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Mon, 23 Nov 2009 04:03:12 +0100, Carl Worth wrote:
> I agree that "normal" should be easier too. So I just need to win you
> over to my notion of "normal", (and teach you of the ways of the magic
> space bar).
As I mentioned, I rarely read mail in a linear fashion; I don't want it
to show me another message, I want to see the index again. I'm torn over
whether I just want the index to always be visible; having the full
screen available to view a single thread is awfully nice. It seems like
a 'I'm done, go back to the index' is just what is needed here.
> [*] We should perhaps fix 'a' to remove the "unread" tag from any
> messages that _are_ wholly visible in the current window. It's really
> only when an entire thread fits this one, and I *did* read it, that I
> end up reaching for the 'A' binding.
yes, that does make a lot of sense, and do precisely the same for the
'x' key, leaving 'q' the way to get out of a message without changing
it at all.
> If we did that, then we could make 'a' do archive-go-to-next-message
> and 'A' do archive-return-to-search-view. What would you think about
> that?
I'd take 'x' for 'return to search view; otherwise you're going to wear
out my pinky reaching for the shift key. That leaves us with three
commands:
'a': advance to next message, archiving current thread, marking read
messages. ('A' forces all messages in thread to be marked as read)
'x': exit to search view, archiving current thread, marking read
messages. ('X' forces all messages in thread to be marked as read)
'q': quit back to search view, leaving thread tags unmodified.
There's a slightly weird asymmetry here -- there's no way to advance to
the next thread and not mark messages.
--
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/20091122/11c8a12a/attachment.pgp>
[notmuch] [PATCH] Add SCons build files.
On Sun, Nov 22, 2009 at 9:11 PM, Carl Worth wrote: > > But I'm afraid I really don't want to switch away from just using (GNU) > make for the actual compilation. > > I don't know anything about scons, but if you can use it to write a > python script that just does the configuration step, (outputting a > Makefile.config say), then that might be very interesting. Well, to me, part of the appeal of SCons is that it doesn't generate Makefiles.This article is a little old, but the first three sections are a pretty good rundown on the limitations of Make. http://www.scons.org/wiki/FromMakeToScons If you really want a tool that generates Makefiles, take a look at CMake. Unfortunately, I think CMake tries to do too much with the Makefiles and they become close to unreadable. In the attempt I made to come up with CMake build files, CMake generates at least 3800 lines of Makefiles (from a starting point of 30 lines of build files). > Some people > have recently told me that python would be a much more sane language for > doing configuration in than shell. Well, Python is a much more sane language for doing just about anything as far as I'm concerned. :) > I don't know if they're right or not, but I'm (somewhat) willing to have > multiple implementations of the configure script (since there's always > the option to just skip it and configure Makefile.config manually). But > I'm definitely not willing to have multiple build systems. I think that having multiple different configuration systems would be pretty awful, especially if people make changes to their favourite configuration system and hope that someone else fixes the others. > Meanwhile, the only advantage I know for automake is that once it's > setup, adding a new file to compile is as simple as adding one file to a > list in the Makefile.am. We've already got notmuch as easy as that with > just adding a file to a list in Makefile.local. Once SCons is set up, adding a new file is just a matter of adding the name of the file to a list as well. CMake is the same, and I'm sure that other systems are similar. > So I'd very much like to continue exploring what we can do with our own > configuration system, (in whatever language/language(s) make sense). It would seem to me that we would be re-inventing a lot of the work already done by other people. > Thanks for listening, Same here. -- Jeff Ollie
[notmuch] [PATCH] fix compiler warnings
On Sun, Nov 22, 2009 at 9:22 PM, Carl Worth wrote:
> On Sun, 22 Nov 2009 17:11:03 +0200, Dirk-Jan C. Binnema gmail.com> wrote:
>>
>> - ? ?write(2, msg, sizeof(msg)-1);
>> + ? ?if (write(2, msg, sizeof(msg)-1) < 0) {
>> + ? ? ? ? /* ignore...*/
>> + ? ?}
>
> I don't like the gratuitous conditional here. It clutters the code and
> make is less clear. If we're just trying to squelch a warning about an
> unused return value from a function, then I think I'd rather see:
>
> ? ? ? ?ssize_t ignored;
>
> ? ? ? ?ignored = write (2, msg, sizeof (msg) - 1);
Isn't the usual method for ignoring return values casting to void?
(void) write (2, msg, sizeof (msg) - 1);
--
Jeff Ollie
[notmuch] notmuch 'index' mode.
On Mon, 23 Nov 2009 07:06:06 +0100, Carl Worth wrote: > On Fri, 20 Nov 2009 23:35:29 -0800, Keith Packard > wrote: > > I posted a patch adding an 'index' mode to notmuch and though I'd > > explain my idea. Most mail systems provide a 'folder view' mode which > > displays the set of folders and a count of messages in each folder. I > > used this myself as the first sort of which messages I want to read. > > I've just pushed this set of patches out now. > > I like it quite a bit. Here are some thoughts: > > * The mode documentation really needs to walk the user through how to > setup a custom set of folders. You can use the standard emacs customization interface, although it's not exactly well documented there. Additional docs are clearly indicated. > * It's not opening my "to-me" folder for some reason. (I thought it > was the '-' at first, but "xorg-board" is working fine). I can debug > this later. It shouldn't work on xorg-board either -- it just skips forward one 'word' and assumes it's gotten the folder name. Lame programming, I know. Should be easy to fix. > * The presentation is impressively spartan[*]. :-) What more do you need? Pretty fonts? Icons? A pony? > If we spruce this up a bit, I think we'll want to make this the default > view of "M-x notmuch". Let's figure out what we want it to look like then. I suggest that we use some font tricks (bold/regular) to highlight folders with un-archived mail. I'd also like to be able to create a hierarchy. > Oh, and instead of just documenting how to set a variable in .emacs we > should just provide commands to add/remove folders. That seems doable; it really only takes two text fields after all. > I think the number of threads matching the search is the only > interesting number actually. Otherwise, you just end up printing a bunch > of big numbers that the user doesn't need for anything. Threads or messages? Threads are more expensive to compute, and when the number is zero, it means the same thing. But, it is surprising to see a huge number in the folder view and then get only a handful of threads in the search view. Perhaps if the count is small enough we can go through and actually figure out how many threads are involved. > So maybe the user configures a search template to use for each automatic > tag or so? Ack! I suggest that the simpler approach of just duplicating the search field will work fine in practice. Otherwise, you're talking miles of UI goo, and constantly confused users. Really, you can use emacs to edit these things if you get too many. > It's only when I get my search results down below a particular > threshold that I decide I want to read everything linearly. I have started doing this sometimes too. But, I still skim things like the mesa list and only read a few by clicking through and 'x'ing back. -- 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/20091122/9db66e2b/attachment-0001.pgp>
[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags
On Mon, 23 Nov 2009 07:31:04 +0100, Carl Worth wrote: > OK. You win. That looks pretty good to me. So we need to do the 'mark all that have been seen read' change, then we can do the rest of this switch. Not sure how to make that work, as we need to know what has been displayed, and you can display bits of the window in lots of different ways (even using the mouse!) -- 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/20091122/06b91513/attachment.pgp>
[notmuch] [PATCH] ANSI escapes in "new" only when output is a tty
On Mon, 23 Nov 2009 06:12:09 +0100, Carl Worth wrote: > So that's totally broken and we should come up with a way to fix it. Tracking directory mtime instead of just looking at the read-only bit would let us skip directories that haven't seen any change in content. Tracking directory contents would let us easily detect name changes (add/remove/rename). -- 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/20091122/36b83be5/attachment.pgp>
