[notmuch] A few patches
On Mon, 01 Mar 2010 14:13:05 +0100 "Sebastian Spaeth" wrote: > > > to count everything. Anyone have a better option for what the > > > give-me-everything syntax should be? > > > > notmuch count '' > > > > The search patterns limit the matched messages/folders. An empty > > pattern should match everything. > > I agree that '' should work, but then I would expect to have '*' work > as well. Is there a reason not to have both at the same time? Both > make sense. Try out this patch. It works both ways. -- Mike Kelly -- next part -- A non-text attachment was scrubbed... Name: 0001-Support-notmuch-count-with-no-args-or.patch Type: text/x-patch Size: 772 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100301/b02342df/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100301/b02342df/attachment.pgp>
[notmuch] Introducing notmuchsync
On Mon, 01 Mar 2010 13:43:24 -0500, Ben Gamari wrote:
> Excerpts from Michal Sojka's message of Mon Mar 01 12:18:55 -0500 2010:
> > > How do you propose that the backends keep track of what mail has been
> > > indexed?
> >
> > For example by using Xapian metadata:
> > notmuch->xapian_db->set_metadata ("git-head", sha1);
>
> However, this means that the backend would need to know about the
> indexing database, which seems to me like a implementation detail that
> should be hidden from the backend (perhaps? Maybe not, I suppose). I guess
> this all
> depends upon how much we want to abstract out the backends.
I do not see why the databse should be hidded. It will be easier to
implement if the backend knows about it. Also, I'm not sure whether this
should be called "backend". From certain point of view Xapian can be
considered as backend and mail store implemetation will be a frontend.
- Michal
[notmuch] noneatall - a silly web interface for notmuch
DraX on IRC asked, so here's a git repository: git://github.com/dme/noneatall.git dme. -- David Edmondson, http://dme.org
[notmuch] noneatall - a silly web interface for notmuch
Whilst thinking about web interfaces for notmuch I decided that it would be quicker to implement one and play rather than trying to consider all possibilities. The result is noneatall[1]. It's _very_ simple and pretty nasty. Please look at the source before you use it - there are no doubt a variety of security holes. Feel free to use, enhance, etc. It would be good if improvements were made available to all. Teaser pictures: - a list of messages (tag:notmuch in this case): http://dme.org/notmuch/index-20100301.png - a displayed forest: http://dme.org/notmuch/thread-20100301.png Footnotes: [1] http://dme.org/notmuch/noneatall dme. -- David Edmondson, http://dme.org
[notmuch] [PATCH 2/2] Emacs code for replying only to sender (bound to 'R' key)
This is probably a very stupid implementation. I do not know elisp well, so I appreciate advises on how to avoid code duplication. Signed-off-by: Michal Sojka --- notmuch.el | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index 6482170..fb567f2 100644 --- a/notmuch.el +++ b/notmuch.el @@ -79,6 +79,7 @@ (define-key map "m" 'message-mail) (define-key map "f" 'notmuch-show-forward-current) (define-key map "r" 'notmuch-show-reply) +(define-key map "R" 'notmuch-show-reply-to-sender) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) @@ -479,6 +480,23 @@ buffer." (let ((message-id (notmuch-show-get-message-id))) (notmuch-reply message-id))) +(defun notmuch-reply-to-sender (query-string) + (switch-to-buffer (generate-new-buffer "notmuch-draft")) + (call-process notmuch-command nil t nil "reply" "--sender-only" query-string) + (message-insert-signature) + (goto-char (point-min)) + (if (re-search-forward "^$" nil t) + (progn + (insert "--text follows this line--") + (forward-line))) + (message-mode)) + +(defun notmuch-show-reply-to-sender () + "Begin composing a reply to the sender of the current message in a new buffer." + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(notmuch-reply-to-sender message-id))) + (defun notmuch-show-forward-current () "Forward the current message." (interactive) -- 1.7.0
[notmuch] [PATCH 1/2] Allow replying only to sender
This adds --sender-only option to reply command, which makes the reply
go only to the original sender.
Signed-off-by: Michal Sojka
---
notmuch-reply.c |9 +++--
notmuch.1 |6 ++
notmuch.c |3 +++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 98f6442..5814313 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -23,6 +23,8 @@
#include "notmuch-client.h"
#include "gmime-filter-reply.h"
+static notmuch_bool_t sender_only = FALSE;
+
static void
reply_part_content (GMimeObject *part)
{
@@ -246,6 +248,7 @@ add_recipients_from_message (GMimeMessage *reply,
};
const char *from_addr = NULL;
unsigned int i;
+unsigned int max;
/* Some mailing lists munge the Reply-To header despite it being A Bad
* Thing, see http://www.unicom.com/pw/reply-to-harmful.html
@@ -262,8 +265,8 @@ add_recipients_from_message (GMimeMessage *reply,
reply_to_map[0].header = "from";
reply_to_map[0].fallback = NULL;
}
-
-for (i = 0; i < ARRAY_SIZE (reply_to_map); i++) {
+max = sender_only ? 1 : ARRAY_SIZE (reply_to_map);
+for (i = 0; i < max; i++) {
const char *addr, *recipients;
recipients = notmuch_message_get_header (message,
@@ -443,6 +446,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
fprintf (stderr, "Invalid value for --format: %s\n", opt);
return 1;
}
+ } else if (STRNCMP_LITERAL (argv[i], "--sender-only") == 0) {
+ sender_only = TRUE;
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
return 1;
diff --git a/notmuch.1 b/notmuch.1
index 282ad98..7220145 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -258,6 +258,12 @@ Includes subject and quoted message body.
.BR headers-only
Only produces In-Reply-To, References, To, Cc, and Bcc headers.
.RE
+.TP 4
+.B \-\-sender\-only
+
+Only setup the To: header as described above, not the additional Cc
+headers.
+.RE
See the
.B "SEARCH SYNTAX"
diff --git a/notmuch.c b/notmuch.c
index 87479f8..13df953 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -233,6 +233,9 @@ command_t commands[] = {
"\t\t\t\tOnly produces In-Reply-To, References, To\n"
"\t\t\t\tCc, and Bcc headers.\n"
"\n"
+ "\t\t--sender-only\n"
+ "\t\t\tReply only to sender.\n"
+ "\n"
"\t\tSee \"notmuch help search-terms\" for details of the search\n"
"\t\tterms syntax." },
{ "tag", notmuch_tag_command,
--
1.7.0
[notmuch] Introducing notmuchsync
On Mon, 01 Mar 2010 11:27:07 -0500, Ben Gamari wrote:
> > 2. get the list of new mails which need to be indexed
> >(current notmuch does recursive file traversal, for git-based store
> >it will be something like system("git diff-tree --name-status ...")
> >
> Is this really necessary? Another option (which I believe has been
> mentioned here in the past) is to simply pass notmuch new a list of
> message "paths" to add (although I'm not sure if many mail delivery
> programs give you that sort of information).
This could also be possible, but now, you say "notmuch new" and notmuch
itself figure out what to index. If passing notmuch a list on files to
index will be the only supported way, it might be hard for new users to
start with notmuch. A nice thing on notmuch is that it can be used
almost without any configuration.
> How do you propose that the backends keep track of what mail has been
> indexed?
For example by using Xapian metadata:
notmuch->xapian_db->set_metadata ("git-head", sha1);
> > Now, if we have this, it would be very easy to add support for
> > Maildir-based mail-store. The implementation of the first two methods
> > would be the same as what is currently in notmuch and the third method
> > would rename files in mailstore if certain tags (such as unread) are
> > added or removed. In case of rename, notmuch database would be
> > immediately updated to reflect the change.
> >
> The interface here seems a little vague. How would the backend notify
> notmuch that the filename has changed?
notmuch new
The idea is that tags changed by notmuch are stored immediately (and
database is updated accordingly), whereas when the mail store is changed
by an external tool, you must explicitly ask notmuch to notice that.
> > So to summarize, I think there should be an abstract layer for
> > handling different types of mail-store. I can see at least three
> > possible implementations of this abstract interface: 1) immutable
> > mail-store (as currently implemented in notmuch) 2) Maildir-based
> > mail-store for limited synchronization with other Maildir tools and
> > 3) git-based mail-store for full synchronization.
>
> Don't forget mbox. It seems like it would be pretty trivial to
> implement (although I'm not sure what performance would look like).
I personally do not use mboxes, so I'm not interested in them.
> > I've already started working on this, but I'm still in the state where I
> > mainly study how notmuch works in order not to break its current
> > functionality.
>
> With all of this infrastructure, it seems like it wouldn't be too
> difficult to support messages from multiple backends in a single index.
> Not sure if people would be interested enough to warrant the added
> complexity though.
I'm currently not interested in such a functionality, but we can add it
later if there is a need.
Bye
Michal
[notmuch] [PATCH] notmuch-show: Do not output (null) when the message body is empty
Signed-off-by: Sebastian Spaeth
---
notmuch-show.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 0f10797..4c794c4 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -310,10 +310,12 @@ format_part_json (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
- show_part_content (part, stream_memory);
+show_part_content (part, stream_memory);
part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM
(stream_memory));
-
- printf (", \"content\": %s", json_quote_str (ctx, (char *)
part_content->data));
+ if (part_content->data != NULL)
+ printf (", \"content\": %s", json_quote_str (ctx, (char *)
part_content->data));
+ else
+ printf (", \"content\": \"\"");
}
fputs ("}", stdout);
--
1.6.3.3
[notmuch] more json woes
More json woes... This mail makes json parser commit suicide:
"body": [{"id": 1, "content-type": "text/html"}, {"id": 2,
"content-type": "text/plain", "content": (null)}
and yes, it has empty mime parts.
Sebastian
[notmuch] [PATCH] notmuch-show: add tags to json output
The previous json patches forgot to add the notmuch tags to the json output.
This is inconsistent to the text output so here they are. We just output a
'tags' field that sends a space delimited list of json-encoded notmuch tags.
Signed-off-by: Sebastian Spaeth
---
notmuch-show.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 1a1d601..0f10797 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -138,10 +138,11 @@ format_message_json (const void *ctx, notmuch_message_t
*message, unused (int in
{
void *ctx_quote = talloc_new (ctx);
-printf ("\"id\": %s, \"match\": %s, \"filename\": %s",
+printf ("\"id\": %s, \"match\": %s, \"filename\": %s, \"tags\": %s",
json_quote_str (ctx_quote, notmuch_message_get_message_id
(message)),
notmuch_message_get_flag (message, NOTMUCH_MESSAGE_FLAG_MATCH) ?
"true" : "false",
- json_quote_str (ctx_quote, notmuch_message_get_filename (message)));
+ json_quote_str (ctx_quote, notmuch_message_get_filename (message)),
+ json_quote_str (ctx_quote, _get_tags_as_string (ctx_quote,
message)));
talloc_free (ctx_quote);
}
--
1.6.3.3
[notmuch] [Sebastian Spaeth] A gentle introduction to notmuch.el users
I have added a section to http://notmuchmail.org/emacstips/ that tries to describe the common workflow of notmuch.el users. It is not finished yet, and it might better belong on a page of it's own. I also recognize that it probably overlaps with James' new page on initial tagging somewhat, but I was thinking of a kind of gentle tutorial that links to specific FAQ entries, mail threads and pages for deeper discussions of specific issues. Corrections, additions, feedback (and deletions) welcome. Sebastian
[notmuch] [Sebastian Spaeth] Re: [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
On Tue, 23 Feb 2010 12:56:15 -0800, Carl Worth wrote: [JSON patch] > Anyway, very well done! I've applied this now with one change: I might be dumb. But does the json output really not provide the notmuch tags of a message as the text output does, and is that intentional? I was trying to make notmuchsync work with json, but tag syncing is hard without getting access to the notmuch tags. If that is an oversight, I will have a look at the tag output. Sebastian
[notmuch] [Sebastian Spaeth] Pull requests
Resending as this did not get through the list somehow. Sorry, if it pops up twice now -- next part -- An embedded message was scrubbed... From: Sebastian Spaeth <sebast...@sspaeth.de> Subject: no subject Date: Mon, 01 Mar 2010 15:13:31 +0100 Size: 2430 URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100301/059017a1/attachment.mht>
[notmuch] What's so great about notmuch?
On Fri, 26 Feb 2010 12:08:49 -0800, Carl Worth wrote: >What's your favorite thing about notmuch? It is simple and fast. It lets me use emacs as MUA which I tried before. But I always gave up on GNUS. >What about notmuch makes it distinctive compared to other email >programs? Did I mention fast? Also it brings me the convenience of "spotlight" searching all your mails in OS X to Linux. >If someone were to implement a new email system from scratch, but >capturing the "ideas" of notmuch, what would it have to have? - "virtual folders" aka tags - a library that can be used by 3rd party UIs - a huge backlog of uncommited submissions ;) (SCNR) - I think thunderbird is actually getting closer to notmuch in version 3. Sebastian
[notmuch] [PATCH] notmuch-new: Respect maildir flags when importing a new message
When importing a new mail do check for maildir tags and assign corresponding
notmuch tags.
Based on a patch by Michiel Buddingh and
subsequently modified by Tim Stoakes, Stewart Smith, and Sebastian Spaeth (see
mail thread around mail id:20100210031339.GH16686 at mail.rocksoft.com)
Do note that this will only add tags when importing a really new message, and
will not do anything when detecting a file rename (although someone should
really make it honor file renames as well). Deleteing an existing message in
another IMAP client will therefore not trigger tagging (as it counts as a file
rename).
Signed-off-by: Sebastian Spaeth
---
I cleaned up the patch by Stewart Smith a bit more, but it's basically his last
version of the patch. The biggest caveat is really that file renames won't
cause any change. So this approach is really only part of the solution to sync
with e.g. thunderbird usage.
notmuch-new.c | 64 -
1 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..5a75950 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -39,6 +39,7 @@ typedef struct {
int total_files;
int processed_files;
int added_messages;
+notmuch_bool_t tag_maildir;
struct timeval tv_start;
_filename_list_t *removed_files;
@@ -169,6 +170,60 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
return 0;
}
+/* Tag new mail according to its Maildir attribute flags.
+ *
+ * Test if the mail file's filename contains any of the
+ * standard Maildir attributes, and translate these to
+ * the corresponding standard notmuch tags.
+ *
+ * If the message is not marked as 'seen', or if no
+ * flags are present, tag as 'inbox, unread'.
+ */
+static void
+derive_tags_from_maildir_flags (notmuch_message_t *message,
+ const char * path)
+{
+int seen = FALSE;
+int end_of_flags = FALSE;
+size_t l = strlen(path);
+
+/* Non-experimental message flags start with this */
+char * i = strstr(path, ":2,");
+i = (i) ? i : strstr(path, "!2,"); /* This format is used on VFAT */
+if (i != NULL) {
+ i += 3;
+ for (; i < (path + l) && !end_of_flags; i++) {
+ switch (*i) {
+ case 'F' :
+ notmuch_message_add_tag (message, "maildir::flagged");
+ break;
+ case 'R': /* replied */
+ notmuch_message_add_tag (message, "maildir::replied");
+ break;
+ case 'D':
+ notmuch_message_add_tag (message, "maildir::draft");
+ break;
+ case 'S': /* seen */
+ seen = TRUE;
+ break;
+ case 'T': /* trashed */
+ notmuch_message_add_tag (message, "maildir::trashed");
+ break;
+ case 'P': /* passed */
+ notmuch_message_add_tag (message, "maildir::forwarded");
+ break;
+ default:
+ end_of_flags = TRUE;
+ break;
+ }
+ }
+}
+
+if (i == NULL || !seen) {
+ tag_inbox_and_unread (message);
+}
+}
+
/* Examine 'path' recursively as follows:
*
* o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -299,6 +354,8 @@ add_files_recursive (notmuch_database_t *notmuch,
strcmp (entry->d_name, ".notmuch") ==0)
{
continue;
+ } else {
+ state->tag_maildir = TRUE;
}
next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
@@ -412,7 +469,12 @@ add_files_recursive (notmuch_database_t *notmuch,
/* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
- tag_inbox_and_unread (message);
+ if (state->tag_maildir) {
+ derive_tags_from_maildir_flags (message,
+ entry->d_name);
+ } else {
+ 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] A few patches
> > to count everything. Anyone have a better option for what the > > give-me-everything syntax should be? > > notmuch count '' > > The search patterns limit the matched messages/folders. An empty pattern > should match everything. I agree that '' should work, but then I would expect to have '*' work as well. Is there a reason not to have both at the same time? Both make sense. Sebastian
[notmuch] Introducing notmuchsync
Excerpts from Michal Sojka's message of Mon Mar 01 12:18:55 -0500 2010:
> > Is this really necessary? Another option (which I believe has been
> > mentioned here in the past) is to simply pass notmuch new a list of
> > message "paths" to add (although I'm not sure if many mail delivery
> > programs give you that sort of information).
>
> This could also be possible, but now, you say "notmuch new" and notmuch
> itself figure out what to index. If passing notmuch a list on files to
> index will be the only supported way, it might be hard for new users to
> start with notmuch. A nice thing on notmuch is that it can be used
> almost without any configuration.
It seems like a script in contrib/ would suffice.
>
> > How do you propose that the backends keep track of what mail has been
> > indexed?
>
> For example by using Xapian metadata:
> notmuch->xapian_db->set_metadata ("git-head", sha1);
However, this means that the backend would need to know about the
indexing database, which seems to me like a implementation detail that
should be hidden from the backend (perhaps? Maybe not, I suppose). I guess this
all
depends upon how much we want to abstract out the backends.
>
> > > Now, if we have this, it would be very easy to add support for
> > > Maildir-based mail-store. The implementation of the first two methods
> > > would be the same as what is currently in notmuch and the third method
> > > would rename files in mailstore if certain tags (such as unread) are
> > > added or removed. In case of rename, notmuch database would be
> > > immediately updated to reflect the change.
> > >
> > The interface here seems a little vague. How would the backend notify
> > notmuch that the filename has changed?
>
> notmuch new
>
> The idea is that tags changed by notmuch are stored immediately (and
> database is updated accordingly), whereas when the mail store is changed
> by an external tool, you must explicitly ask notmuch to notice that.
>
Certainly, I understand that and believe that that is the only sane
approach. However, you currently have no mechanism in your interface to
allow the backend to notify notmuch that the file name has changed.
Considering this is the sole value identifying the message to notmuch,
you definitely need to tell notmuch about the change.
> > Don't forget mbox. It seems like it would be pretty trivial to
> > implement (although I'm not sure what performance would look like).
>
> I personally do not use mboxes, so I'm not interested in them.
Fair enough. Just figured it wouldn't be too difficult (although I know
very little about the format).
> > With all of this infrastructure, it seems like it wouldn't be too
> > difficult to support messages from multiple backends in a single index.
> > Not sure if people would be interested enough to warrant the added
> > complexity though.
>
> I'm currently not interested in such a functionality, but we can add it
> later if there is a need.
Certainly. Just throwing out ideas.
- Ben
[notmuch] [PATCH] notmuch-show: add tags to json output
On Mon, 1 Mar 2010 16:39:06 +0100, Sebastian Spaeth wrote: > The previous json patches forgot to add the notmuch tags to the json > output. This is inconsistent to the text output so here they are. We > just output a 'tags' field that sends a space delimited list of > json-encoded notmuch tags. > > Signed-off-by: Sebastian Spaeth I agree we need tags in json output, but I think that making the client parse the string of (space delimited?) tags defeats a bit the purpose of having json output. What do you think about "tags": [ "inbox", "unread" ] instead of "tags": "inbox unread"
[notmuch] [PATCH] notmuch-show: add tags to json output
On Mon, 01 Mar 2010 13:26:52 -0400, David Bremner wrote: > On Mon, 1 Mar 2010 16:39:06 +0100, Sebastian Spaeth SSpaeth.de> wrote: > > The previous json patches forgot to add the notmuch tags to the json > > output. This is inconsistent to the text output so here they are. We > > just output a 'tags' field that sends a space delimited list of > > json-encoded notmuch tags. > > > > Signed-off-by: Sebastian Spaeth > > I agree we need tags in json output, but I think that making the client > parse the string of (space delimited?) tags defeats a bit the purpose of > having json output. What do you think about > >"tags": [ "inbox", "unread" ] > > instead of > > "tags": "inbox unread" I agree that having the JSON "tags" output field be an array of strings makes the most sense. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100301/0fd37ca6/attachment.pgp>
[notmuch] What's so great about notmuch?
On Fri, 26 Feb 2010 12:08:49 -0800, Carl Worth wrote: >What's your favorite thing about notmuch? I can process my inbox in a linear fassion (by pressing space). During that, I'm not distracted by various GUI elements, which remind me how many other emails I have to read. I can fully concentrate on one topic and it makes my email processing faster. > >What about notmuch makes it distinctive compared to other email >programs? Fast searching. Easy to use Emacs GUI (I use Emacs a lot, but I was never able to configure Gnus to suit me). >If someone were to implement a new email system from scratch, but >capturing the "ideas" of notmuch, what would it have to have? Synchronziation of mail and tags on multiple computers. Michal
[notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)
On Fri, 26 Feb 2010 12:00:06 -0800, Carl Worth wrote:
> [This mail started as some off-topic rambling in my reply to the
> notmuch-reply script. So that's why it starts on one topic and ends
> somewhere else entirely.]
>
> I'm currently avoiding any locking failures with notmuch commands by
> running "notmuch new" manually, (rather than from a cron job). And it
> occurs to me that running "notmuch new" manually has a certain
> benefit---it allows me to bring in a chunk of mail, and then process all
> of that (either by replying, or setting aside to a particular project or
> "todo" tag, etc.) without getting distracted by other mail coming in.
That's what I like on notmuch too. (I also don't use cron.)
> I know that what I really want instead of "todo" is a way to express the
> reason I'm postponing a message. There's probably some resource I'm
> missing that I need before I can deal with it. Perhaps that's:
>
> * I can't decide on this until I'm with co-workers and can talk about
> this.
>
> * I can't resolve this until I'm at the office with the right hardware
> to test.
>
> * I need to remember to do something with this when I'm at home.
>
> * I need a nice block of "discretionary time" to be able to give this
> topic the attention I want to.
>
> * I need to look at this message again on this Saturday.
>
> So what I really want to do is to tag things based on those criteria,
> ("office", "magic-hardware", "home", "discretionary", "2010-02-27"),
> which I can at least do now.
>
> But what I'm currently missing is a way for the folders based on these
> tags to only appear at the right times, (when the resource is
> available).
It seems I have the same needs as you. I use Emacs's org-mode for
managing my TODO list and I find org-remember very useful in this
context.
It works like this: I have a global key binding (C-c r) for org-remember
and whenever I press this key a new buffer appears. I write my TODO item
there and after C-c C-c the buffer is appended to my TODO list. What is
important, is that the remember buffer may be pre-filled with some
information based on major mode of from where it was invoked. This
information might be a so called org-link (a link to another entity
which emacs can work with). David Bremner did some work
(id:8763805hr2.fsf at pivot.cs.unb.ca) to support links to mails in
notmuch, but I haven't tried it yet.
So I'd like to process my mail like this: If I cannot complete the mail
immediately, I'll press "C-c r" to create a new TODO item where I
mention what is needed for completing this mail. The TODO item will
automatically contain a link to the original message. I can also add
some Org Mode properties such as SCHEDULED or DEADLINE. Then I remove
unread and inbox tags from the message. This way I'll process the whole
inbox until it becomes empty.
Then I will use org-mode's Agenda view to show me what to do just now.
Thanks to the properties such as SCHEDULED, I won't see items which I do
not want to see today.
If I complete some TODO item, I'll use org-link to immediately jump to
the original message and I'll reply to it.
The only problem here is some kind of duplication. Org-mode has its own
tags and these have nothing in common with notmuch tags. So, in order to
use tags your TODO items and mails, you would need to tag them twice
(once in notmuch and once in org).
What might work here would be some kind of integration between Org's
Agenda view and notmuch search. But I do not have an exact idea how this
could look like.
Bye
Michal
[notmuch] Introducing notmuchsync
Excerpts from Michal Sojka's message of Mon Mar 01 03:57:26 -0500 2010:
> Hi, when you are on this topic, I'll put my two cents in. Currently
> notmuch works only with mail-store comprised of files. People want to
> work with their mails on multiple computers so there are several
> ideas/solutions how to achieve that. Notmuchsync, which plays well with
> offlineimap, is one of them. Another idea is Git based mail-store, which
> I would really like to have.
>
> If we want to make notmuch work with Git-based mail-store, it will be
> necessary to make the interface between notmuch core and mail-store
> handling code a bit more abstract so that it will be possible to
> configure mail-store type to be used.
I agree that we should make notmuch less tied to maildirs as the only
possible mailstore. In the interest of simplicity, however, it's
important to keep the surface area of the interface down.
>
> This abstract mail-store interface will contain methods for the
> following operations:
> 1. read mail identified by a path from mail-store
>(current notmuch uses fread() for this, for git this will be
>something like system("git cat-file ..."))
>
Yep. Seems reasonable.
> 2. get the list of new mails which need to be indexed
>(current notmuch does recursive file traversal, for git-based store
>it will be something like system("git diff-tree --name-status ...")
>
Is this really necessary? Another option (which I believe has been
mentioned here in the past) is to simply pass notmuch new a list of
message "paths" to add (although I'm not sure if many mail delivery
programs give you that sort of information). How do you propose that the
backends keep track of what mail has been indexed?
> 3. add/remove tags for a given message (this will be NULL for current
>notmuch functionality)
Yep, makes sense.
>
> This way the mail-store will be able to store both mails and
> corresponding tags and in case of git, it will be easy to synchronize
> mail-stores on multiple computers.
Sounds great. Can't wait!
>
> Now, if we have this, it would be very easy to add support for
> Maildir-based mail-store. The implementation of the first two methods
> would be the same as what is currently in notmuch and the third method
> would rename files in mailstore if certain tags (such as unread) are
> added or removed. In case of rename, notmuch database would be
> immediately updated to reflect the change.
>
The interface here seems a little vague. How would the backend notify
notmuch that the filename has changed?
> So to summarize, I think there should be an abstract layer for
> handling different types of mail-store. I can see at least three
> possible implementations of this abstract interface: 1) immutable
> mail-store (as currently implemented in notmuch) 2) Maildir-based
> mail-store for limited synchronization with other Maildir tools and
> 3) git-based mail-store for full synchronization.
Don't forget mbox. It seems like it would be pretty trivial to
implement (although I'm not sure what performance would look like).
>
> I've already started working on this, but I'm still in the state where I
> mainly study how notmuch works in order not to break its current
> functionality.
With all of this infrastructure, it seems like it wouldn't be too
difficult to support messages from multiple backends in a single index.
Not sure if people would be interested enough to warrant the added
complexity though.
>
> I'd like to hear what others think about this idea.
>
That's my uninformed opinion. Take it with an appropriately sized grain
of salt. I do think that some sort of abstraction will be necessary
though. I'm glad you're taking a look at this. I've been wanting to
start hacking away at some sort of prototype git backend, but I haven't
wanted to start before we have the appropriate infrastructure in
notmuch.
Cheers,
- Ben
[notmuch] [PATCH] A simple approach to maildir flags
On Fri, 26 Feb 2010 14:49:25 -0500, Mike Kelly wrote: > The following patches attempt to provide a simple, extendable approach > to handling the 'Seen' maildir flag. To appease (hopefully) everyone, it > will only do this for new messages. This means that people coming from > another MUA won't be stuck with 30,000 unread messages, for example. > > It should be simple to extend this to other maildir flags, too, if > people want them and can decide on what tags they should correspond to. Personally, I like the seen messages not to be in inbox (by default) as either: 1) I'm importing an old Maildir, in which case if it's read it's probably been dealt with 2) i've used another mail client, same as above. -- Stewart Smith
[notmuch] [PATCH] Support for deletion (patch included)
On Thu, 25 Feb 2010 01:00:04 +0100 (CET), racin at free.fr wrote: > Hi Carl, > > > Could you also write a commit message describing what the patch does? > > The easiest way for me to apply that would be if you would create a git > > commit, then run "git format-patch origin/master" and mail the resulting > > files, (the "git send-email" command can be used here, or you can insert > > the files into a mail-composition buffer and modify them as needed). > > > > OK, here it is (comments below). I had trouble splitting the patches into a > patch series; I > found git add -p, but isn't there a better interface for selecting > patches? What about "git gui"? Michal
[notmuch] Introducing notmuchsync
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth wrote:
> Elsewhere in the thread Jameson Rollins wrote:
> > I should have mentioned in my previous mail that I think this tool is
> > a great idea, and I plan on using it. I just hope that all of it's
> > functionality will be integrated directly into notmuch itself.
>
> I think that's the open question still. How much of this kind of
> functionality do we integrate into notmuch itself. I don't know the
> answer to that question yet, but I'm quite happy to see people
> experimenting with doing scripts like this on top of notmuch already.
Hi, when you are on this topic, I'll put my two cents in. Currently
notmuch works only with mail-store comprised of files. People want to
work with their mails on multiple computers so there are several
ideas/solutions how to achieve that. Notmuchsync, which plays well with
offlineimap, is one of them. Another idea is Git based mail-store, which
I would really like to have.
If we want to make notmuch work with Git-based mail-store, it will be
necessary to make the interface between notmuch core and mail-store
handling code a bit more abstract so that it will be possible to
configure mail-store type to be used.
This abstract mail-store interface will contain methods for the
following operations:
1. read mail identified by a path from mail-store
(current notmuch uses fread() for this, for git this will be
something like system("git cat-file ..."))
2. get the list of new mails which need to be indexed
(current notmuch does recursive file traversal, for git-based store
it will be something like system("git diff-tree --name-status ...")
3. add/remove tags for a given message (this will be NULL for current
notmuch functionality)
This way the mail-store will be able to store both mails and
corresponding tags and in case of git, it will be easy to synchronize
mail-stores on multiple computers.
Now, if we have this, it would be very easy to add support for
Maildir-based mail-store. The implementation of the first two methods
would be the same as what is currently in notmuch and the third method
would rename files in mailstore if certain tags (such as unread) are
added or removed. In case of rename, notmuch database would be
immediately updated to reflect the change.
So to summarize, I think there should be an abstract layer for
handling different types of mail-store. I can see at least three
possible implementations of this abstract interface: 1) immutable
mail-store (as currently implemented in notmuch) 2) Maildir-based
mail-store for limited synchronization with other Maildir tools and
3) git-based mail-store for full synchronization.
I've already started working on this, but I'm still in the state where I
mainly study how notmuch works in order not to break its current
functionality.
I'd like to hear what others think about this idea.
Bye
Michal
Re: [notmuch] Introducing notmuchsync
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth cwo...@cworth.org wrote: Elsewhere in the thread Jameson Rollins wrote: I should have mentioned in my previous mail that I think this tool is a great idea, and I plan on using it. I just hope that all of it's functionality will be integrated directly into notmuch itself. I think that's the open question still. How much of this kind of functionality do we integrate into notmuch itself. I don't know the answer to that question yet, but I'm quite happy to see people experimenting with doing scripts like this on top of notmuch already. Hi, when you are on this topic, I'll put my two cents in. Currently notmuch works only with mail-store comprised of files. People want to work with their mails on multiple computers so there are several ideas/solutions how to achieve that. Notmuchsync, which plays well with offlineimap, is one of them. Another idea is Git based mail-store, which I would really like to have. If we want to make notmuch work with Git-based mail-store, it will be necessary to make the interface between notmuch core and mail-store handling code a bit more abstract so that it will be possible to configure mail-store type to be used. This abstract mail-store interface will contain methods for the following operations: 1. read mail identified by a path from mail-store (current notmuch uses fread() for this, for git this will be something like system(git cat-file ...)) 2. get the list of new mails which need to be indexed (current notmuch does recursive file traversal, for git-based store it will be something like system(git diff-tree --name-status ...) 3. add/remove tags for a given message (this will be NULL for current notmuch functionality) This way the mail-store will be able to store both mails and corresponding tags and in case of git, it will be easy to synchronize mail-stores on multiple computers. Now, if we have this, it would be very easy to add support for Maildir-based mail-store. The implementation of the first two methods would be the same as what is currently in notmuch and the third method would rename files in mailstore if certain tags (such as unread) are added or removed. In case of rename, notmuch database would be immediately updated to reflect the change. So to summarize, I think there should be an abstract layer for handling different types of mail-store. I can see at least three possible implementations of this abstract interface: 1) immutable mail-store (as currently implemented in notmuch) 2) Maildir-based mail-store for limited synchronization with other Maildir tools and 3) git-based mail-store for full synchronization. I've already started working on this, but I'm still in the state where I mainly study how notmuch works in order not to break its current functionality. I'd like to hear what others think about this idea. Bye Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Support for deletion (patch included)
On Thu, 25 Feb 2010 01:00:04 +0100 (CET), ra...@free.fr wrote: Hi Carl, Could you also write a commit message describing what the patch does? The easiest way for me to apply that would be if you would create a git commit, then run git format-patch origin/master and mail the resulting files, (the git send-email command can be used here, or you can insert the files into a mail-composition buffer and modify them as needed). OK, here it is (comments below). I had trouble splitting the patches into a patch series; I found git add -p, but isn't there a better interface for selecting patches? What about git gui? Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Thoughts on not seeing messages I can't deal with (yet, or now, or here...)
On Fri, 26 Feb 2010 12:00:06 -0800, Carl Worth cwo...@cworth.org wrote: [This mail started as some off-topic rambling in my reply to the notmuch-reply script. So that's why it starts on one topic and ends somewhere else entirely.] I'm currently avoiding any locking failures with notmuch commands by running notmuch new manually, (rather than from a cron job). And it occurs to me that running notmuch new manually has a certain benefit---it allows me to bring in a chunk of mail, and then process all of that (either by replying, or setting aside to a particular project or todo tag, etc.) without getting distracted by other mail coming in. That's what I like on notmuch too. (I also don't use cron.) I know that what I really want instead of todo is a way to express the reason I'm postponing a message. There's probably some resource I'm missing that I need before I can deal with it. Perhaps that's: * I can't decide on this until I'm with co-workers and can talk about this. * I can't resolve this until I'm at the office with the right hardware to test. * I need to remember to do something with this when I'm at home. * I need a nice block of discretionary time to be able to give this topic the attention I want to. * I need to look at this message again on this Saturday. So what I really want to do is to tag things based on those criteria, (office, magic-hardware, home, discretionary, 2010-02-27), which I can at least do now. But what I'm currently missing is a way for the folders based on these tags to only appear at the right times, (when the resource is available). It seems I have the same needs as you. I use Emacs's org-mode for managing my TODO list and I find org-remember very useful in this context. It works like this: I have a global key binding (C-c r) for org-remember and whenever I press this key a new buffer appears. I write my TODO item there and after C-c C-c the buffer is appended to my TODO list. What is important, is that the remember buffer may be pre-filled with some information based on major mode of from where it was invoked. This information might be a so called org-link (a link to another entity which emacs can work with). David Bremner did some work (id:8763805hr2@pivot.cs.unb.ca) to support links to mails in notmuch, but I haven't tried it yet. So I'd like to process my mail like this: If I cannot complete the mail immediately, I'll press C-c r to create a new TODO item where I mention what is needed for completing this mail. The TODO item will automatically contain a link to the original message. I can also add some Org Mode properties such as SCHEDULED or DEADLINE. Then I remove unread and inbox tags from the message. This way I'll process the whole inbox until it becomes empty. Then I will use org-mode's Agenda view to show me what to do just now. Thanks to the properties such as SCHEDULED, I won't see items which I do not want to see today. If I complete some TODO item, I'll use org-link to immediately jump to the original message and I'll reply to it. The only problem here is some kind of duplication. Org-mode has its own tags and these have nothing in common with notmuch tags. So, in order to use tags your TODO items and mails, you would need to tag them twice (once in notmuch and once in org). What might work here would be some kind of integration between Org's Agenda view and notmuch search. But I do not have an exact idea how this could look like. Bye Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] What's so great about notmuch?
On Fri, 26 Feb 2010 12:08:49 -0800, Carl Worth cwo...@cworth.org wrote: What's your favorite thing about notmuch? I can process my inbox in a linear fassion (by pressing space). During that, I'm not distracted by various GUI elements, which remind me how many other emails I have to read. I can fully concentrate on one topic and it makes my email processing faster. What about notmuch makes it distinctive compared to other email programs? Fast searching. Easy to use Emacs GUI (I use Emacs a lot, but I was never able to configure Gnus to suit me). If someone were to implement a new email system from scratch, but capturing the ideas of notmuch, what would it have to have? Synchronziation of mail and tags on multiple computers. Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [Sebastian Spaeth] Pull requests
Resending as this did not get through the list somehow. Sorry, if it pops up twice now ---BeginMessage--- From git repository git://github.com/spaetz/notmuch-all-feature.git I would like to advocate the following branches for quick pulling. Each contains 1 or 2 patches. They have all been based on todays cworth/master, so it should be really painless. I divided them into 3 'trivial' branches which should not require lots of discussion and 3 'proposed' which I would really encourage to pull as they improve my user experience. TRIVIAL === issue12_fontify-date Very trivial and obvious oversight. Make the date the same color as the rest of the headers. id:874omet1su@servo.finestructure.net issue18-F-for-notmuch-folder Bind 'F' to get us to notmuch-folder from notmuch-search mail id:1265889583-25406-1-git-send-email-...@dme.org issue19-notmuch-buffer-use-subject Rather than using the ugly thread id as buffer name, use a nicer description based on the subject. mail id:m1wryiayhg@watt.gilman.jhu.edu PROPOSED The following patches are some that really improve my life.. issue17-colorize-lines Let us display thread lines colored based on (configurable) tag-color pairs mail id:87aavpb3wh@servo.finestructure.net issue20,22-citations Show first and last few lines of a citation, not only the first few lines. Show citations colorized. based on mail id:1266226909-19360-1-git-send-email-...@dme.org and mail id:1266403911-16567-1-git-send-email-...@dme.org issue21-tag-by-thread-or-region Allow to tag multiple threads by selecting a region. This one is really, really handy. mail id:87sk90ragj@jhu.edu POSSIBLY issue8-maildirtag-import This is the respect maildir patch (with contributions from various people). As there is a similar patch from pioto, this might require some discussion before pulling. based on thread mail id:20100210031339.gh16...@mail.rocksoft.com Thanks for considering. Sebastian P.S. I reworked my feature-all branch to contain above topic branches and merging those branches into feature-all. This will hopefully allow easier rebasing if patches bit-rot. The downside is that I killed the history of that git repository. Please do a clean repull if you already have it. ---End Message--- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] A few patches
to count everything. Anyone have a better option for what the give-me-everything syntax should be? notmuch count '' The search patterns limit the matched messages/folders. An empty pattern should match everything. I agree that '' should work, but then I would expect to have '*' work as well. Is there a reason not to have both at the same time? Both make sense. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] What's so great about notmuch?
On Fri, 26 Feb 2010 12:08:49 -0800, Carl Worth cwo...@cworth.org wrote: What's your favorite thing about notmuch? It is simple and fast. It lets me use emacs as MUA which I tried before. But I always gave up on GNUS. What about notmuch makes it distinctive compared to other email programs? Did I mention fast? Also it brings me the convenience of spotlight searching all your mails in OS X to Linux. If someone were to implement a new email system from scratch, but capturing the ideas of notmuch, what would it have to have? - virtual folders aka tags - a library that can be used by 3rd party UIs - a huge backlog of uncommited submissions ;) (SCNR) - I think thunderbird is actually getting closer to notmuch in version 3. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] notmuch-show: add tags to json output
The previous json patches forgot to add the notmuch tags to the json output.
This is inconsistent to the text output so here they are. We just output a
'tags' field that sends a space delimited list of json-encoded notmuch tags.
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
notmuch-show.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 1a1d601..0f10797 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -138,10 +138,11 @@ format_message_json (const void *ctx, notmuch_message_t
*message, unused (int in
{
void *ctx_quote = talloc_new (ctx);
-printf (\id\: %s, \match\: %s, \filename\: %s,
+printf (\id\: %s, \match\: %s, \filename\: %s, \tags\: %s,
json_quote_str (ctx_quote, notmuch_message_get_message_id
(message)),
notmuch_message_get_flag (message, NOTMUCH_MESSAGE_FLAG_MATCH) ?
true : false,
- json_quote_str (ctx_quote, notmuch_message_get_filename (message)));
+ json_quote_str (ctx_quote, notmuch_message_get_filename (message)),
+ json_quote_str (ctx_quote, _get_tags_as_string (ctx_quote,
message)));
talloc_free (ctx_quote);
}
--
1.6.3.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] more json woes
More json woes... This mail makes json parser commit suicide:
body: [{id: 1, content-type: text/html}, {id: 2,
content-type: text/plain, content: (null)}
and yes, it has empty mime parts.
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] notmuch-show: Do not output (null) when the message body is empty
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
notmuch-show.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 0f10797..4c794c4 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -310,10 +310,12 @@ format_part_json (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, text, *)
!g_mime_content_type_is_type (content_type, text, html))
{
- show_part_content (part, stream_memory);
+show_part_content (part, stream_memory);
part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM
(stream_memory));
-
- printf (, \content\: %s, json_quote_str (ctx, (char *)
part_content-data));
+ if (part_content-data != NULL)
+ printf (, \content\: %s, json_quote_str (ctx, (char *)
part_content-data));
+ else
+ printf (, \content\: \\);
}
fputs (}, stdout);
--
1.6.3.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Introducing notmuchsync
On Mon, 01 Mar 2010 11:27:07 -0500, Ben Gamari bgam...@gmail.com wrote: 2. get the list of new mails which need to be indexed (current notmuch does recursive file traversal, for git-based store it will be something like system(git diff-tree --name-status ...) Is this really necessary? Another option (which I believe has been mentioned here in the past) is to simply pass notmuch new a list of message paths to add (although I'm not sure if many mail delivery programs give you that sort of information). This could also be possible, but now, you say notmuch new and notmuch itself figure out what to index. If passing notmuch a list on files to index will be the only supported way, it might be hard for new users to start with notmuch. A nice thing on notmuch is that it can be used almost without any configuration. How do you propose that the backends keep track of what mail has been indexed? For example by using Xapian metadata: notmuch-xapian_db-set_metadata (git-head, sha1); Now, if we have this, it would be very easy to add support for Maildir-based mail-store. The implementation of the first two methods would be the same as what is currently in notmuch and the third method would rename files in mailstore if certain tags (such as unread) are added or removed. In case of rename, notmuch database would be immediately updated to reflect the change. The interface here seems a little vague. How would the backend notify notmuch that the filename has changed? notmuch new The idea is that tags changed by notmuch are stored immediately (and database is updated accordingly), whereas when the mail store is changed by an external tool, you must explicitly ask notmuch to notice that. So to summarize, I think there should be an abstract layer for handling different types of mail-store. I can see at least three possible implementations of this abstract interface: 1) immutable mail-store (as currently implemented in notmuch) 2) Maildir-based mail-store for limited synchronization with other Maildir tools and 3) git-based mail-store for full synchronization. Don't forget mbox. It seems like it would be pretty trivial to implement (although I'm not sure what performance would look like). I personally do not use mboxes, so I'm not interested in them. I've already started working on this, but I'm still in the state where I mainly study how notmuch works in order not to break its current functionality. With all of this infrastructure, it seems like it wouldn't be too difficult to support messages from multiple backends in a single index. Not sure if people would be interested enough to warrant the added complexity though. I'm currently not interested in such a functionality, but we can add it later if there is a need. Bye Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch-show: add tags to json output
On Mon, 1 Mar 2010 16:39:06 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: The previous json patches forgot to add the notmuch tags to the json output. This is inconsistent to the text output so here they are. We just output a 'tags' field that sends a space delimited list of json-encoded notmuch tags. Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de I agree we need tags in json output, but I think that making the client parse the string of (space delimited?) tags defeats a bit the purpose of having json output. What do you think about tags: [ inbox, unread ] instead of tags: inbox unread ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 2/2] Emacs code for replying only to sender (bound to 'R' key)
This is probably a very stupid implementation. I do not know elisp well, so I appreciate advises on how to avoid code duplication. Signed-off-by: Michal Sojka sojk...@fel.cvut.cz --- notmuch.el | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/notmuch.el b/notmuch.el index 6482170..fb567f2 100644 --- a/notmuch.el +++ b/notmuch.el @@ -79,6 +79,7 @@ (define-key map m 'message-mail) (define-key map f 'notmuch-show-forward-current) (define-key map r 'notmuch-show-reply) +(define-key map R 'notmuch-show-reply-to-sender) (define-key map | 'notmuch-show-pipe-message) (define-key map w 'notmuch-show-save-attachments) (define-key map V 'notmuch-show-view-raw-message) @@ -479,6 +480,23 @@ buffer. (let ((message-id (notmuch-show-get-message-id))) (notmuch-reply message-id))) +(defun notmuch-reply-to-sender (query-string) + (switch-to-buffer (generate-new-buffer notmuch-draft)) + (call-process notmuch-command nil t nil reply --sender-only query-string) + (message-insert-signature) + (goto-char (point-min)) + (if (re-search-forward ^$ nil t) + (progn + (insert --text follows this line--) + (forward-line))) + (message-mode)) + +(defun notmuch-show-reply-to-sender () + Begin composing a reply to the sender of the current message in a new buffer. + (interactive) + (let ((message-id (notmuch-show-get-message-id))) +(notmuch-reply-to-sender message-id))) + (defun notmuch-show-forward-current () Forward the current message. (interactive) -- 1.7.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch-show: add tags to json output
On Mon, 01 Mar 2010 13:26:52 -0400, David Bremner brem...@unb.ca wrote: On Mon, 1 Mar 2010 16:39:06 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: The previous json patches forgot to add the notmuch tags to the json output. This is inconsistent to the text output so here they are. We just output a 'tags' field that sends a space delimited list of json-encoded notmuch tags. Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de I agree we need tags in json output, but I think that making the client parse the string of (space delimited?) tags defeats a bit the purpose of having json output. What do you think about tags: [ inbox, unread ] instead of tags: inbox unread I agree that having the JSON tags output field be an array of strings makes the most sense. jamie. pgpXzjuEJUGIs.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Introducing notmuchsync
On Mon, 01 Mar 2010 13:43:24 -0500, Ben Gamari bgam...@gmail.com wrote: Excerpts from Michal Sojka's message of Mon Mar 01 12:18:55 -0500 2010: How do you propose that the backends keep track of what mail has been indexed? For example by using Xapian metadata: notmuch-xapian_db-set_metadata (git-head, sha1); However, this means that the backend would need to know about the indexing database, which seems to me like a implementation detail that should be hidden from the backend (perhaps? Maybe not, I suppose). I guess this all depends upon how much we want to abstract out the backends. I do not see why the databse should be hidded. It will be easier to implement if the backend knows about it. Also, I'm not sure whether this should be called backend. From certain point of view Xapian can be considered as backend and mail store implemetation will be a frontend. - Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
