[notmuch] [PATCH 3/3] notmuch-show: identify which messages printed matched the query string
The show command outputs all messages in the threads that match the
search-terms. This patch introduces a 'match:[01]' entry to the 'message{'
line output by the show command. Value of 1 indicates that the message is
matching the search expression.
Signed-off-by: Bart Trojanowski
---
notmuch-show.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 8599c6c..e9f0883 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -155,9 +155,10 @@ show_message (void *ctx, notmuch_message_t *message, int
indent)
const char *name, *value;
unsigned int i;
-printf ("\fmessage{ id:%s depth:%d filename:%s\n",
+printf ("\fmessage{ id:%s depth:%d match:%d filename:%s\n",
notmuch_message_get_message_id (message),
indent,
+ notmuch_message_get_flag (message,
NOTMUCH_MSG_FLAG_MATCHING_SEARCH),
notmuch_message_get_filename (message));
printf ("\fheader{\n");
--
1.6.4.4.2.gc2f148
[notmuch] [PATCH 2/3] have _notmuch_thread_create mark which messages matched the query
When _notmuch_thread_create() is given a query string, it can return more
messages than just those matching the query. To distinguish those that
matched the query expression, the MATCHING_SEARCH flag is set
appropriately.
Signed-off-by: Bart Trojanowski
---
lib/notmuch.h |1 +
lib/thread.cc |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index c232c58..3974820 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -686,6 +686,7 @@ notmuch_message_get_filename (notmuch_message_t *message);
/* Message flags */
typedef enum _notmuch_message_flag {
+NOTMUCH_MSG_FLAG_MATCHING_SEARCH,
} notmuch_message_flag_t;
/* Get a value of a flag for the email corresponding to 'message'. */
diff --git a/lib/thread.cc b/lib/thread.cc
index 58d88c2..9e4cb5c 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -132,6 +132,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_t *message)
{
time_t date;
+notmuch_message_t *hashed_message;
date = notmuch_message_get_date (message);
@@ -142,6 +143,13 @@ _thread_add_matched_message (notmuch_thread_t *thread,
thread->newest = date;
thread->matched_messages++;
+
+if (g_hash_table_lookup_extended (thread->message_hash,
+ notmuch_message_get_message_id (message), NULL,
+ (void **) _message)) {
+ notmuch_message_set_flag (hashed_message,
+ NOTMUCH_MSG_FLAG_MATCHING_SEARCH, 1);
+}
}
static void
--
1.6.4.4.2.gc2f148
[notmuch] [PATCH 1/3] message: add flags to notmuch_message_t
This patch allows for different flags, internal to notmuch, to be set on a
message object. The patch does not define any such flags, just the
facilities to manage these flags.
Signed-off-by: Bart Trojanowski
---
lib/message.cc | 19 +++
lib/notmuch.h | 14 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 1e325e2..e0834f1 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -37,6 +37,7 @@ struct _notmuch_message {
char *filename;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
+unsigned long flags;
Xapian::Document doc;
};
@@ -108,6 +109,7 @@ _notmuch_message_create (const void *talloc_owner,
message->doc_id = doc_id;
message->frozen = 0;
+message->flags = 0;
/* Each of these will be lazily created as needed. */
message->message_id = NULL;
@@ -445,6 +447,23 @@ notmuch_message_get_filename (notmuch_message_t *message)
return message->filename;
}
+notmuch_bool_t
+notmuch_message_get_flag (notmuch_message_t *message,
+ notmuch_message_flag_t flag)
+{
+return message->flags & (1 << flag);
+}
+
+void
+notmuch_message_set_flag (notmuch_message_t *message,
+ notmuch_message_flag_t flag, notmuch_bool_t enable)
+{
+if (enable)
+ message->flags |= (1 << flag);
+else
+ message->flags &= ~(1 << flag);
+}
+
time_t
notmuch_message_get_date (notmuch_message_t *message)
{
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 8bba442..c232c58 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -684,6 +684,20 @@ notmuch_message_get_replies (notmuch_message_t *message);
const char *
notmuch_message_get_filename (notmuch_message_t *message);
+/* Message flags */
+typedef enum _notmuch_message_flag {
+} notmuch_message_flag_t;
+
+/* Get a value of a flag for the email corresponding to 'message'. */
+notmuch_bool_t
+notmuch_message_get_flag (notmuch_message_t *message,
+ notmuch_message_flag_t flag);
+
+/* Set a value of a flag for the email corresponding to 'message'. */
+void
+notmuch_message_set_flag (notmuch_message_t *message,
+ notmuch_message_flag_t flag, notmuch_bool_t value);
+
/* Get the date of 'message' as a time_t value.
*
* For the original textual representation of the Date header from the
--
1.6.4.4.2.gc2f148
[notmuch] notmuch show should tell us what messages matched the search expression
The following 3 patches implement this feature.
Internally the message object learns about flags. Only a single flag is
defined to denote that a message matched the search expression.
That flag is then rendered on the "message{" line in the output of
notmuch show like this:
message{ id:... depth:4 match:0 filename:...
message{ id:... depth:4 match:1 filename:...
This can now be used by UI interfaces to hide or collapse less
interesting messages.
-Bart
[notmuch] [PATCH 4/4] notmuch-new: New cmdline option --tag=.
The list of tags to be applied by 'notmuch new' can be configured in
the configuration file. This command line option can be used to
override the list of tags from the coonfiguration file on the command
line. You may repeat the option several times if you want to apply
more than one tag:
notmuch new --tag=apple --tag=orange
This is useful, for example, if you have an archive of messages you
would like to add to the database with a special tag so that they can
be easily identified later. To do that, you could simply copy the files
from the archive to the database directory and then index them all with:
notmuch new --tag=prehistory
Tags to be applied every time 'notmuch new' is run can be specified in
the configuration file. One-time tags for individual runs can be
specified on the command line with this new option.
Signed-off-by: Jan Janak
---
notmuch-new.c | 40 ++--
notmuch.c |8 +++-
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 10745e8..94036da 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -26,6 +26,9 @@ static volatile sig_atomic_t do_add_files_print_progress = 0;
static notmuch_config_t *config = NULL;
+static char **cmdline_tags = NULL;
+static unsigned int cmdline_tags_count = 0;
+
static void
handle_sigalrm (unused (int signal))
{
@@ -76,12 +79,19 @@ apply_tags (notmuch_message_t *message)
char** tags;
unsigned int count, i;
-if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
- return;
+if (cmdline_tags_count) {
+ for (i = 0; i < cmdline_tags_count; i++) {
+ if (cmdline_tags[i])
+ notmuch_message_add_tag (message, cmdline_tags[i]);
+ }
+} else {
+ if ((tags = notmuch_config_get_new_tags (config, )) == NULL)
+ return;
-for (i = 0; i < count; i++) {
- if (tags[i])
- notmuch_message_add_tag (message, tags[i]);
+ for (i = 0; i < count; i++) {
+ if (tags[i])
+ notmuch_message_add_tag (message, tags[i]);
+ }
}
}
@@ -413,7 +423,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
int ret = 0;
struct stat st;
const char *db_path;
-char *dot_notmuch_path;
+char *dot_notmuch_path, *opt;
+char **tmp;
struct sigaction action;
int i;
@@ -423,6 +434,23 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
for (i = 0; i < argc && argv[i][0] == '-'; i++) {
if (STRNCMP_LITERAL (argv[i], "--verbose") == 0) {
add_files_state.verbose = 1;
+ } else if (STRNCMP_LITERAL (argv[i], "--tag=") == 0) {
+ opt = argv[i] + sizeof ("--tag=") - 1;
+ /* FIXME: We should check for leading and trailing white-space in
+* option value here and remove it.
+*/
+ if (*opt == '\0') {
+ fprintf (stderr, "Option value missing: %s\n", argv[i]);
+ return 1;
+ }
+ tmp = talloc_realloc (ctx, cmdline_tags, char*,
+ cmdline_tags_count + 1);
+ if (tmp == NULL) {
+ fprintf (stderr, "Notmuch ran out of memory.\n");
+ return 1;
+ }
+ tmp[cmdline_tags_count++] = opt;
+ cmdline_tags = tmp;
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
return 1;
diff --git a/notmuch.c b/notmuch.c
index b84e284..fb0c2a7 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -123,7 +123,7 @@ command_t commands[] = {
"\t\tInvoking notmuch with no command argument will run setup if\n"
"\t\tthe setup command has not previously been completed." },
{ "new", notmuch_new_command,
- "[--verbose]",
+ "[--verbose] [--tag=]",
"\t\tFind and import new messages to the notmuch database.",
"\t\tScans all sub-directories of the mail directory, performing\n"
"\t\tfull-text indexing on new messages that are found. Each new\n"
@@ -145,6 +145,12 @@ command_t commands[] = {
"\t\t\tVerbose operation. Shows paths of message files as\n"
"\t\t\tthey are being indexed.\n"
"\n"
+ "\t\t--tag=\n"
+ "\n"
+ "\t\t\tAdd the tag to all messages newly added to the\n"
+ "\t\t\tdatabase. You may repeat this option several times if\n"
+ "\t\t\tyou want to add more tags.\n"
+ "\n"
"\t\tNote: \"notmuch new\" runs (other than the first run) will\n"
"\t\tskip any read-only directories, so you can use that to mark\n"
"\t\tdirectories that will not receive any new mail (and make\n"
--
1.6.3.3
[notmuch] [PATCH 3/4] notmuch-setup: Copy/create the new section with tags for 'notmuch-new'.
If the user runs 'notmuch setup' and there is no configuration file yet
then we also add the new section [new] to the configuration file and
set the tags option as:
tags=inbox;unread
This will be picked up by 'notmuch new' and all new mail added to the
database will be tagged with the two tags as before.
If the user already has a configuration file and runs 'notmuch setup'
then we just copy whatever tags we find in the old configuration file
to the new one. If there are no tags in the old configuration file then
we assume that the user configured notmuch that way and the new config
file would also have no tags in the section [new].
We never ask the user interactively for the list of tags to be used by
'notmuch new', it is assumed that beginners would want to stick to the
defaults and advanced users can edit the configuration manually.
Signed-off-by: Jan Janak
---
notmuch-client.h |4
notmuch-config.c | 40
notmuch-setup.c | 14 ++
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 0fb9c19..bb7d3d4 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -187,6 +187,10 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
char **
notmuch_config_get_new_tags (notmuch_config_t *config, size_t *length);
+void
+notmuch_config_set_new_tags (notmuch_config_t *config, const char *tags[],
+size_t length);
+
notmuch_bool_t
debugger_is_active (void);
diff --git a/notmuch-config.c b/notmuch-config.c
index 7f62a80..e884621 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -54,6 +54,16 @@ static const char user_config_comment[] =
" recipient list of replies, and will set the From address based on the\n"
" address to which the original email was addressed.\n";
+static const char new_config_comment[] =
+" Configuration section for 'notmuch new'\n"
+"\n"
+" The only supported value at the moment is 'tags. This option contains
a\n"
+" list of tags (separated by ';') that should be automatically applied
to\n"
+" newly added messages.\n"
+"\n"
+" Note that 'notmuch new' also has a command line option which can be
used\n"
+" to add additional tags to the ones configured here.\n";
+
struct _notmuch_config {
char *filename;
GKeyFile *key_file;
@@ -174,6 +184,7 @@ notmuch_config_open (void *ctx,
GError *error = NULL;
int is_new = 0;
char *notmuch_config_env = NULL;
+const char* def_new_tags[2] = {"inbox", "unread"};
if (is_new_ret)
*is_new_ret = 0;
@@ -270,6 +281,20 @@ notmuch_config_open (void *ctx,
}
}
+/* If we have no configuration file then we configure "inbox" and "unread"
+ * tags by default for 'notmuch new'. This ensures that the Emacs mode
+ * would still work as expected.
+ *
+ * We do not ask the user for tags to be used by 'notmuch new'. That's too
+ * much detail for beginners and others can edit the configuration file by
+ * hand.
+ */
+if (is_new) {
+ notmuch_config_set_new_tags (config, def_new_tags,
+sizeof(def_new_tags) /
+sizeof(const char*));
+}
+
/* When we create a new configuration file here, we add some
* comments to help the user understand what can be done. */
if (is_new) {
@@ -279,6 +304,8 @@ notmuch_config_open (void *ctx,
database_config_comment, NULL);
g_key_file_set_comment (config->key_file, "user", NULL,
user_config_comment, NULL);
+ g_key_file_set_comment (config->key_file, "new", NULL,
+ new_config_comment, NULL);
}
if (is_new_ret)
@@ -494,3 +521,16 @@ notmuch_config_get_new_tags (notmuch_config_t *config,
size_t *length)
*length = config->new_tags_length;
return config->new_tags;
}
+
+void
+notmuch_config_set_new_tags (notmuch_config_t *config,
+const char *tags[],
+size_t length)
+{
+g_key_file_set_string_list (config->key_file,
+ "new", "tags",
+ tags, length);
+
+talloc_free (config->new_tags);
+config->user_other_email = NULL;
+}
diff --git a/notmuch-setup.c b/notmuch-setup.c
index d06fbf8..c1406db 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -96,6 +96,8 @@ notmuch_setup_command (unused (void *ctx),
notmuch_config_t *config;
char **old_other_emails;
size_t old_other_emails_len;
+char **new_tags;
+unsigned int new_tags_len;
GPtrArray *other_emails;
unsigned int i;
int is_new;
@@ -147,6 +149,18 @@ notmuch_setup_command (unused (void *ctx),
other_emails->len);
g_ptr_array_free (other_emails, TRUE);
+/* If we already have a
[notmuch] [PATCH 1/4] notmuch-new: Remove tag_add_inbox_unread in favor of a generic solution.
Instead of adding 'inbox' and 'unread' tags directly in the code of
'notmuch-new', we can specify a list of tags to be added to newly
created messages with a configuration file option or a command line
option. That's more flexible, it allows the user to select which tags
should be added.
Signed-off-by: Jan Janak
---
notmuch-new.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index e32b92a..9970407 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -41,13 +41,6 @@ handle_sigint (unused (int sig))
}
static void
-tag_inbox_and_unread (notmuch_message_t *message)
-{
-notmuch_message_add_tag (message, "inbox");
-notmuch_message_add_tag (message, "unread");
-}
-
-static void
add_files_print_progress (add_files_state_t *state)
{
struct timeval tv_now;
@@ -198,7 +191,6 @@ add_files_recursive (notmuch_database_t *notmuch,
/* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
- tag_inbox_and_unread (message);
break;
/* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
--
1.6.3.3
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
I would like to propose that we make the list of tags applied by 'notmuch new' configurable. Right now notmuch applies two tags to all new messages added to the database, 'inbox' and 'unread'. The two tags are added by the C code in notmuch-new.c and they cannot be changed without editing the source file and recompiling notmuch. The four patches that follow this email allow for configuring the tags to be added by 'notmuch new' either in the configuration file or on the command line. This change was motivated by my desire to remove both tags from newly added messages. My rules for adding these two tags are more complex and I do it in a script run after 'notmuch new'. Instead of 'inbox' and 'unread', I configure 'notmuch new' to add a new tag called 'new' (and only that one). This tag marks newly added messages that haven't been properly tagged yet by my auto-tagging scripts. The last script I run after 'notmuch new' removes that tag. My auto-tagging scripts process only messages with the tag 'new'. On a side note; It may seem logical to add/omit the tag 'unread' directly in 'notmuch new' based on the Maildir flags extracted from the filename of the message. I suggest that we don't do that in 'notmuch new'. A better way would be writing a small script or command that can be run *after* 'notmuch new'. We could then distribute it with notmuch (maybe with other small tagging scripts for common situations). I think Maildir flags should be processed after 'notmuch new' is because if there are multiple copies of a message with different flags, we may need to see all flags from all filenames to set corresponding tags properly and we may also need to take the directory part into consideration (i.e. the new mail is in 'new', not 'cur'). The list of tags to be applied by notmuch can be configured in the configuration file. There is a new section [new] which contains configuration options for 'notmuch new'. There is only one option called 'tags'. The option contains a semicolon separated list of tags: [new] tags=inbox;unread # Emulate the original behavior One of the patches updates 'notmuch setup' to create the section and add the tags option with tags 'inbox' and 'unread', but only if a new configuration file is being created. If the configuration file already exists then it just copies the contents from the old configuration file to the new one. We do not ask the user for the list of tags in the interactive part, that would have been too much. Users can edit the configuration file manually if they want to change the list of tags. If they create a new configuration file then they probably want to accept the default anyway. There is one catch for users who already have a configuration file and start using the patches. They will need to add the new section and the tags option manually if they want to preserve current behavior of applying 'inbox' and 'unread' automatically by 'notmuch new'. The last patch in the set adds a new command line option to 'notmuch new'. The name of the option is --tag and it can be used to override any tags configured in the configuration file. For example: notmuch new --tag=outbox --tag=read adds the tags 'outbox' and 'read' and ignores any tags from the configuration file. Comments and opinions are welcome! -- Jan
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
* Jan Janak [091124 17:11]: > I would like to propose that we make the list of tags applied by 'notmuch new' > configurable. Right now notmuch applies two tags to all new messages added to > the database, 'inbox' and 'unread'. The two tags are added by the C code in > notmuch-new.c and they cannot be changed without editing the source file and > recompiling notmuch. I like it. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.
It turns out that this ID has id: prefixed (which I thought was fine because I'm frequently doing another query with it). But git send-email doesn't strip that, so this was not threaded correctly. Would this be better with the id: prefix stripped? Jed
[notmuch] [PATCH -v4] notmuch.el: Add face support to search and show mode
On Wed, 25 Nov 2009 10:28:00 +0530, "Aneesh Kumar K.V" wrote:
> This add two faces, notmuch-show-subject-face and
> notmuch-tag-face. The first face is used to show the subject
> line in the notmuch-show-mode and the second one to show tags
> in the notmuch-search-mode.
>
First, I definetly think fontification is the way to go instead of
the adhoc/crappy way that cworth and I have been doing this in the
past.
[snip]
> +(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")
> +
So what happens if I have Subject: in my message? We already ran
into a problem where a patch sent the list that included notmuch control
character caused it to go into an infinite loop, I'd prefer our
fontification code be a bit more resilient. At the very least this
should use the font-lock syntax tables stuff to only do header
fontification when inside the header block. This would probably require
that fontification occur before the message is post-processed by
notmuch-show to remove the section markers etc.
Also +1 for more subduded colors than red. :) Possibly consider copying
the message-mode colors, so that there is a bit of consistency between
sending and viewing mail? Might even be able to steal the message-mode
faces by importing their symbols.
[snip]
> (defun notmuch-search-mode ()
>"Major mode for searching mail with notmuch.
> @@ -865,7 +888,18 @@ 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)
> + (if (not notmuch-tag-face-alist)
> + (add-to-list 'notmuch-search-font-lock-keywords (list
> + "\\(([^)]*)$\\)" '(1 'notmuch-tag-face)))
This way of detecting the tags seems ok, but I think it would be nicer
if it could be done even more deterministically. :) One idea that be
neat is to have a --format=sexp for notmuch search, which exports sexps
(probably alists, but could be some other format) for the search results
that can just be eval'd and processed in a cleaner way (and would also
make for nicer APIs in emacs for querying notmuch itself). Actually I
really like the idea of a sexp output mode for show too, instead of the
markers *plots*
> +(progn
> + (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)))
>
I don't really see the point of fontifying all tags the same way if no
tag-faces have been set, especially if none of the rest of the search
results are fontified.
Alex
[notmuch] [PATCH] New function notmuch-show-kill-ring-save-message-id.
Puts current message ID in the kill ring. This is useful any time you want to explicitly refer to the message, such as in the body of another message, through git format-patch, or on IRC. It is bound to "C-c i". Corrected spelling of function name in commit message, and updated to apply against HEAD after c1e16435cfe4471c3415d9f625f7230d59c8afb4 Signed-off-by: Jed Brown --- notmuch.el | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index 907df2c..e3e0e06 100644 --- a/notmuch.el +++ b/notmuch.el @@ -80,6 +80,7 @@ (define-key map "?" 'describe-mode) (define-key map (kbd "TAB") 'notmuch-show-next-button) (define-key map (kbd "M-TAB") 'notmuch-show-previous-button) +(define-key map (kbd "C-c i") 'notmuch-show-kill-ring-save-message-id) map) "Keymap for \"notmuch show\" buffers.") (fset 'notmuch-show-mode-map notmuch-show-mode-map) @@ -663,6 +664,17 @@ which this thread was originally shown." (notmuch-show-markup-message))) (notmuch-show-hide-markers)) +(defun notmuch-show-kill-ring-save-message-id () + "Put the current message id in the kill ring. + +This is useful for referencing messages or running external +queries." + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(kill-new message-id) +(when (called-interactively-p 'interactive) + (message "Saved message ID: \"%s\"" message-id + ;;;###autoload (defun notmuch-show-mode () "Major mode for viewing a thread with notmuch. -- 1.6.5.3
[notmuch] [PATCH] notmuch-show: add option to limit display to only matching messages
This patch adds support for notmuch show --only-matching-messages
which limits the output to only the top level messages matching
the search terms provides.
Example:
$ notmuch search subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b
thread:23d99d0f364f93e90e15df8b42eddb5b July 31 [4/12] Johan Herland;
[RFCv2 00/12] Foreign VCS helper program for CVS repositories (inbox unread)
Note that in this thread 4 out of 12 messages matched. The default show
behaviour is to show all messages in the thread:
$ notmuch show subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep
'message{' | wc -l
12
With the --only-matching-messages option the output is limited to the
matching messages only:
$ notmuch show --only-matching-messages subject:git AND
thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
4
Signed-off-by: Bart Trojanowski
---
notmuch-show.c | 48 +---
notmuch.c |7 +++
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index edebaca..8599c6c 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -211,6 +211,24 @@ notmuch_show_command (void *ctx, unused (int argc), unused
(char *argv[]))
notmuch_thread_t *thread;
notmuch_messages_t *messages;
char *query_string;
+int only_matching = 0;
+int i;
+
+for (i = 0; i < argc && argv[i][0] == '-'; i++) {
+ if (strcmp (argv[i], "--") == 0) {
+ i++;
+ break;
+ }
+if (strcmp(argv[i], "--only-matching-messages") == 0) {
+ only_matching = 1;
+ } else {
+ fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
+ return 1;
+ }
+}
+
+argc -= i;
+argv += i;
config = notmuch_config_open (ctx, NULL, NULL);
if (config == NULL)
@@ -238,21 +256,29 @@ notmuch_show_command (void *ctx, unused (int argc),
unused (char *argv[]))
return 1;
}
-for (threads = notmuch_query_search_threads (query);
-notmuch_threads_has_more (threads);
-notmuch_threads_advance (threads))
-{
- thread = notmuch_threads_get (threads);
+if (only_matching) {
+ messages = notmuch_query_search_messages (query);
+ if (messages == NULL)
+ INTERNAL_ERROR ("No messages.\n");
+ show_messages (ctx, messages, 0);
- messages = notmuch_thread_get_toplevel_messages (thread);
+} else {
+ for (threads = notmuch_query_search_threads (query);
+ notmuch_threads_has_more (threads);
+ notmuch_threads_advance (threads))
+ {
+ thread = notmuch_threads_get (threads);
- if (messages == NULL)
- INTERNAL_ERROR ("Thread %s has no toplevel messages.\n",
- notmuch_thread_get_thread_id (thread));
+ messages = notmuch_thread_get_toplevel_messages (thread);
- show_messages (ctx, messages, 0);
+ if (messages == NULL)
+ INTERNAL_ERROR ("Thread %s has no toplevel messages.\n",
+ notmuch_thread_get_thread_id (thread));
+
+ show_messages (ctx, messages, 0);
- notmuch_thread_destroy (thread);
+ notmuch_thread_destroy (thread);
+ }
}
notmuch_query_destroy (query);
diff --git a/notmuch.c b/notmuch.c
index f45b692..a817ae3 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -177,6 +177,13 @@ command_t commands[] = {
"\t\t(all replies to a particular message appear immediately\n"
"\t\tafter that message in date order).\n"
"\n"
+ "\t\tSupported options for show include:\n"
+ "\n"
+ "\t\t--only-matching-messages\n"
+ "\n"
+ "\t\t\tUsing this option will prevent output of any messages\n"
+ "\t\t\tthat do not match the search terms.\n"
+ "\n"
"\t\tThe output format is plain-text, with all text-content\n"
"\t\tMIME parts decoded. Various components in the output,\n"
"\t\t('message', 'header', 'body', 'attachment', and MIME 'part')\n"
--
1.6.4.4.2.gc2f148
[notmuch] (no subject)
Hi, I find this patch useful for searching my mail. I realize that the option is horrendously long, and I would take any suggestions to shorten it or to use a short op, like -m. -Bart
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
On Tue, 2009-11-24 at 23:10 +0100, Jan Janak wrote: > Instead of 'inbox' and 'unread', I configure > 'notmuch new' to add a new tag called 'new' (and only that one). This tag > marks newly added messages that haven't been properly tagged yet by my > auto-tagging scripts. Oh, brilliant! I like it. Bdale
[notmuch] [PATCH] notmuch-new: Remove the tiresome joke from the output.
As I see this every time I poll for new mail, the joke becomes very old
very quickly. The other instances of "not much" are shown much less
often and have a much more natural style, this one however feels forced,
impairing the humorous effect.
Signed-off-by: Chris "the critic" Wilson
---
notmuch-new.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index e32b92a..3cde3a7 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -483,12 +483,10 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
}
if (add_files_state.added_messages) {
- printf ("Added %d new %s to the database (not much, really).\n",
+ printf ("Added %d new %s to the database.\n",
add_files_state.added_messages,
add_files_state.added_messages == 1 ?
"message" : "messages");
-} else {
- printf ("No new mail---and that's not much.\n");
}
if (elapsed > 1 && ! add_files_state.saw_read_only_directory) {
--
1.6.5.3
[notmuch] [PATCH] New function notmuch-show-kill-message-id, puts current message ID in the kill ring.
This is useful any time you want to explicitly refer to the message, such as in the body of another message, through git format-patch, or on IRC. It is bound to "C-c i". Signed-off-by: Jed Brown --- notmuch.el | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index fa6e7de..071ee5a 100644 --- a/notmuch.el +++ b/notmuch.el @@ -84,6 +84,7 @@ (define-key map "?" 'describe-mode) (define-key map (kbd "TAB") 'notmuch-show-next-button) (define-key map (kbd "M-TAB") 'notmuch-show-previous-button) +(define-key map (kbd "C-c i") 'notmuch-show-kill-ring-save-message-id) map) "Keymap for \"notmuch show\" buffers.") (fset 'notmuch-show-mode-map notmuch-show-mode-map) @@ -698,6 +699,17 @@ which this thread was originally shown." (force-window-update) (redisplay t)) +(defun notmuch-show-kill-ring-save-message-id () + "Put the current message id in the kill ring. + +This is useful for referencing messages or running external +queries." + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(kill-new message-id) +(when (called-interactively-p 'interactive) + (message "Saved message ID: \"%s\"" message-id + ;;;###autoload (defun notmuch-show-mode () "Major mode for viewing a thread with notmuch. -- 1.6.5.3
[notmuch] notmuch 'index' mode.
On 24-11 08:38, Keith Packard wrote: > On Tue, 24 Nov 2009 13:14:07 +0100, Jan Janak wrote: > > > I like this. I think this is much cleaner than the "virtual tag" > > approach. > > A disadvantage I see is that you would not see this 'virtual tags' in > the list of tags on each message. Maybe I don't understand how virtual tags are really supposed to work. I thought that the term "virtual tags" is just another name for "named" search terms and it is named "virtual tags" because they can actually be attached to messages stored in the database. And if I remember it correctly, Carl said somewhere that virtual tags will be added/removed automatically to messages if the corresponding search term gets changed. If my understanding is correct, then we won't be able to show virtual tags along with "normal" tags anyway. We would probably need a separate list just for virtual tags. One of the reasons is that you can add and remove normal tags to messages manually, but you cannot easily do the same with virtual tags. If you remove a virtual tag from a message and then update the search term bound to that virtual tag, as soon as you change the search term, the virtual tag might be added to the message again if the new search expression still matches the message. Unlike real tags, the user won't be able to add and remove virtual tags to messages arbitrarily without the risk that notmuch changes the selection behind his back on the next update of the configuration file (assuming that the search expression is stored in the configuration file). We would probably need to make sure that the user knows which tags are virtual and which are real and that means notmuch would have to present them differently, possibly in a separate list. Thinking more about this, we could probably make it possible to add and remove virtual tags to messages manually by storing the information about what the user did with the virtual tag along with the message (i.e. this virtual tag is pinned to the message so don't remove it when the search term is changed). Maybe I just don't understand how virtual tags are really supposed to work, but it seems to me as a can of worms just waiting to be opened :-). -- Jan
[notmuch] notmuch 'index' mode.
* Keith Packard [091124 11:38]: > A disadvantage I see is that you would not see this 'virtual tags' in > the list of tags on each message. And, we'd have to put the virtual tags > in the .config file or the command line would become a lot less > useful. Speaking of which, we should put the folders in the .config file > in any case, and provide command line syntax to use them. I too would vote for this approach. I'd like to keep as much smarts in the notmuch executable as it would mean less to port to other (non emacs) interfaces. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
On Tue, Nov 24, 2009 at 5:10 PM, Jan Janak wrote: > I would like to propose that we make the list of tags applied by 'notmuch new' > configurable. Right now notmuch applies two tags to all new messages added to > the database, 'inbox' and 'unread'. The two tags are added by the C code in > notmuch-new.c and they cannot be changed without editing the source file and > recompiling notmuch. Personally I would like this. I can't find myself leaving GNUS and so am using notmuch as "just" a search engine. Now I manually remove "inbox" and "unread" after each "new" since they just clutter up an inbox I never read. Cheers, -Brett.
[notmuch] [PATCH] notmuch-count: make sure all created items are freed, even in error paths
Another minor patch, fixing a couple of resource leaks in error paths.
---
notmuch-count.c | 52
1 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/notmuch-count.c b/notmuch-count.c
index 77aa433..b5808f5 100644
--- a/notmuch-count.c
+++ b/notmuch-count.c
@@ -28,7 +28,8 @@ notmuch_count_command (void *ctx, int argc, char *argv[])
notmuch_database_t *notmuch;
notmuch_query_t *query;
char *query_str;
-int i;
+int i, retval;
+
#if 0
char *opt, *end;
int i, first = 0, max_threads = -1;
@@ -76,35 +77,54 @@ notmuch_count_command (void *ctx, int argc, char *argv[])
argc -= i;
argv += i;
+config= NULL;
+query_str = NULL;
+notmuch = NULL;
+query = NULL;
+
config = notmuch_config_open (ctx, NULL, NULL);
-if (config == NULL)
- return 1;
-
-notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
-NOTMUCH_DATABASE_MODE_READ_ONLY);
-if (notmuch == NULL)
- return 1;
-
+if (config == NULL) {
+ retval = 1;
+ goto out;
+}
+
query_str = query_string_from_args (ctx, argc, argv);
if (query_str == NULL) {
fprintf (stderr, "Out of memory.\n");
- return 1;
+ retval = 1;
+ goto out;
}
if (*query_str == '\0') {
fprintf (stderr, "Error: notmuch count requires at least one count
term.\n");
- return 1;
+ retval = 1;
+ goto out;
}
-
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+if (notmuch == NULL) {
+ fprintf (stderr, "Failed to open database at %s\n",
+notmuch_config_get_database_path (config));
+ retval = 1;
+ goto out;
+}
+
query = notmuch_query_create (notmuch, query_str);
if (query == NULL) {
fprintf (stderr, "Out of memory\n");
- return 1;
+ retval = 1;
+ goto out;
}
printf ("%u\n", notmuch_query_count_messages(query));
+retval = 0;
+out:
+talloc_free (query_str);
+notmuch_config_close (config);
notmuch_query_destroy (query);
-notmuch_database_close (notmuch);
-
-return 0;
+if (notmuch) /* _close does not allow NULL */
+ notmuch_database_close (notmuch);
+
+return retval;
}
--
1.6.3.3
[notmuch] interesting project!
Hi Carl, > "Carl" == Carl Worth writes: Carl> I agree that trying to support OOM doesn't make sense without Carl> testing. But that's why I want to test notmuch with memory-fault Carl> injection. We've been doing this with the cairo library with good Carl> success for a while. Carl> As for "unlikely that malloc ever returns NULL", that's simply a Carl> system-configuration away (just turn off overcommit). And I can imagine Carl> notmuch being used in lots of places, (netbooks, web servers, etc.), so Carl> I do want to make it as robust as possible. That is a very laudable goal! But it's also quite hard to achieve, considering that both GMime and Xapian may have some different ideas about that. And at least in the current code, I see fprintfs in 'malloc-returns-NULL'-cases -- but fprintf itself will probably allocate memory too. Also, at least now, the bad?alloc exceptions for C++ are not caught. Of course, that can be changed, but it's just to show that these things are hard to get right. Carl> Thanks for mentioning the hash table. The hash table is one of the few Carl> things that I *am* using from glib right now in notmuch. It's got a Carl> couple of bizarre things about it: Carl> 1. The simpler-appearing g_hash_table_new function is useless Carl> for common cases like hashing strings. It will just leak Carl> memory. So g_hash_table_new_full is the only one worth using. Hmmm, I never noticed that behavior. Tf you are using dynamically allocated strings, GHashTable won't free them for you -- but I can really see how it could (given that it takes generic pointers), so you have to free those yourself. But any memleaks beyond that? Carl> 2. There are two lookup functions, g_hash_table_lookup, and Carl> g_hash_table_lookup_extended. Carl> So, it might make sense if a hash-table interface supported Carl> these two modes well. What's bizarre about GHashTable though, Carl> is that in the "just a set" case, we only use NULL as the Carl> value when inserting. And distinguish "previously inserted Carl> with NULL" from "never inserted" is the one thing that Carl> g_hash_table_lookup can't do. So I've only found that I could Carl> ever use g_hash_table_lookup_extended, (and pass a pair of Carl> NULLs for the return arguments I don't need). Hmmn, well in I found that returning NULL for 'not set' works in many cases, and it makes it quite easy for that. If you need to distinguish between NULL and 'not set', you can use either the _extended version as you mention, or use some special NOT_SET static ptr you can compare with (and handle it appropriately in the destructor). Carl> I definitely like the idea of having tiny, focused libraries that do Carl> one thing and do it well, (and maybe even some things so tiny that Carl> they are actually designed to be copied into the application---like Carl> with gnulib and with Eric's new hash table). Ok; glib fills the role pretty well for me, and I don't really pay for the parts that I don't use. But tastes differ, no problem ;-) Carl> Thanks for understanding. :-) Carl> And I enjoy the conversation, Same here :) 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] notmuch 'index' mode.
On Tue, Nov 24, 2009 at 4:16 AM, Carl Worth wrote: > And notice, I don't think we'll need to do the "virtual tag" thing of > associating a tag name with a search and doing the work of making > notmuch maintain the consistency of that tag and search string. It will > be much more clean (and shouldn't be any less fast) to just do the > searches for the original search terms, (rather than searching for tag > terms that were previously applied by searching for the search terms). > > Then tags become something that are just for manual manipulation. What > do you think? I like this. I think this is much cleaner than the "virtual tag" approach. -- Jan
[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config
On Mon, Nov 23, 2009 at 5:55 AM, Carl Worth wrote: > On Sun, 22 Nov 2009 18:14:20 -0500, Jameson Graef Rollins finestructure.net> wrote: >> 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. > > Well, I chose the relative-path assumptions intentionally. The idea is > that if I move my mail from ~/Mail to ~/mail then the .notmuch directory > moves with it and everything continues to work just fine. Yeah, having relative paths in the database is a really good thing, IMHO. I was pleasantly surprised that notmuch continued working after I moved my mail from one directory to another :-). -- Jan
[notmuch] [PATCH 1/5] make headers locally expandable/collapsable
On Tue, 24 Nov 2009 11:40:24 -0800, Carl Worth wrote: [snip] > Anyway, this is really great stuff, Alexander. Thanks for coding it up! > Awesome thanks. Makes things much more useable anyway. :) > I've pushed it out now, (with a little bit more in the way of commit > messages---thanks for humoring me). > Ahh, come on, Lorem Ipsum was such a clear and detailed commit message. :D > I noticed that I could open and re-collapse a message that notmuch > initially presents as hidden, but I didn't seem to be able to collapse > an initially-open message. Now, I'm sure that's due to broken-ness in > code I wrote myself originally. But as a future-feature request, that > might be some consistency that would be nice to have. > Odd. I wouldn't be suprised were that behavior the case, but I can not reproduce it locally. I totally agree it should be the case, but I seem to be able to expand collapse already open messages without a problem.. alex
[notmuch] [PATCH 1/5] make headers locally expandable/collapsable
On Mon, 23 Nov 2009 23:45:03 -0800, Alexander Botero-Lowry wrote: > --- > notmuch.el | 18 +++--- > 1 files changed, 15 insertions(+), 3 deletions(-) Hmm... no real content for me to reply to here... :-) Anyway, this is really great stuff, Alexander. Thanks for coding it up! I've pushed it out now, (with a little bit more in the way of commit messages---thanks for humoring me). I noticed that I could open and re-collapse a message that notmuch initially presents as hidden, but I didn't seem to be able to collapse an initially-open message. Now, I'm sure that's due to broken-ness in code I wrote myself originally. But as a future-feature request, that might be some consistency that would be nice to have. -Carl
[notmuch] notmuch 'index' mode.
On Mon, 23 Nov 2009 19:43:26 -0800, Keith Packard wrote: > On Mon, 23 Nov 2009 19:16:54 -0800, Carl Worth wrote: > > Then tags become something that are just for manual manipulation. What > > do you think? I really think this is the way to go. > And disadvantages as searching might actually be slow at some point? If this happens, there is nothing to prevent notmuch from caching the search by actually writing a corresponding tag. This could be made automatic by logging the cost of each named search (and perhaps the frequency of making that search), and using a tradeoff function to decide which searches to optimize. Once a search was selected for optimization, there are at least two alternatives, depending on which queries xapian can answer quickly. 1. Log the time and spawn an asynchronous notmuch tag process. Searches for vtag:named-search (vtag: doesn't need to be a keyword, but I'm only distinguishing here for clarity) which was normally translated into long search expression becomes tag:named-search OR newer:timestamp AND (long search expression) This option guarantees that notmuch new remains fast and simple because it does no special tagging, but this query might not be any better. 2. Inform notmuch new that it should apply the chosen tag to messages matching the query and spawn the asynchronous notmuch tag process. Once the tag process has finished, searches for vtag:named-search are translated to tag:named-search. This implies concurrent modification of the database, otherwise it would cause a stall in incoming mail (not important if mass tagging somehow became faster). Admittedly my archive is not huge (100k messages in 3.5 GB plus 1.1 GB for .notmuch) but queries returning a reasonable number of messages are still quite fast. Additionally, searches for tags do not seem to be greatly faster than queries for complex queries returning a similar number of results. Jed
[notmuch] Snippet to jump to message in Gnus from notmuch-show buffer
Hi all, I'm a Gnus user and use notmuch mostly for searching. When I want to reply to a message, I need to get back to Gnus, so that my Gnus posting styles (gcc into that group, right email address, correct signature,...) are applied. Therefore, I created this small snippet. Now C-c C-c inside some message in the *notmuch-show* buffer opens this article in a Gnus *Summary* buffer, where I can reply to it, forward it, ... Of course, the translation from file name to Gnus group name is something that is different for any user. The essence of this code is the call to the org-gnus.el function `org-gnus-follow-link', which takes the group name and the message-id. It's included in Emacsen >= 23. --8<---cut here---start->8--- (require 'notmuch) (defun th-notmuch-file-to-group (file) "Calculate the Gnus group name from the given file name. Example: IN: /home/horn/Mail/Dovecot/uni/INBOX/dbox-Mails/u.4075 OUT: nnimap+Uni:INBOX" (concat "nnimap+" (replace-regexp-in-string "^\\([^/]+\\)/" "\\1:" (replace-regexp-in-string "/dbox-Mails/.*" "" (replace-regexp-in-string "/home/horn/Mail/Dovecot/" "" file) (defun th-notmuch-goto-message-in-gnus () "Open a summary buffer containing the current notmuch article." (interactive) (let ((group (th-notmuch-file-to-group (notmuch-show-get-filename))) (message-id (replace-regexp-in-string "^id:" "" (notmuch-show-get-message-id (message "G: %s, mid: %s" group message-id) (if (and group message-id) (org-gnus-follow-link group message-id) (message "Couldn't get relevant infos for switching to Gnus." (define-key notmuch-show-mode-map (kbd "C-c C-c") 'th-notmuch-goto-message-in-gnus) --8<---cut here---end--->8--- BTW, why does `notmuch-show-get-message-id' prefix the message-id with "id:"? Bye, Tassilo
[notmuch] notmuch 'index' mode.
On Tue, 24 Nov 2009 13:14:07 +0100, Jan Janak wrote: > I like this. I think this is much cleaner than the "virtual tag" > approach. A disadvantage I see is that you would not see this 'virtual tags' in the list of tags on each message. And, we'd have to put the virtual tags in the .config file or the command line would become a lot less useful. Speaking of which, we should put the folders in the .config file in any case, and provide command line syntax to use them. -- 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/20091124/223cea1c/attachment.pgp>
