[notmuch] [PATCH] notmuch: Respect maildir message flags
Michiel Buddingh'(michiel at michielbuddingh.net)@061209-20:55:
>
...
> A new patch is attached. Apologies for the rather verbose Maildir
> handling logic, but I couldn't find a way to minimize the calls to
> is_maildir that was both neat and readable.
Hi notmuch-ers,
My apologies for dredging up an old thread. I don't want to restart the
religious war over whether notmuch should respect Maildir flags -
suffice to say that *I* want that, and the patch posted by Michiel
seemed to be the best way to make that happen.
Since it no longer applies cleanly, I've ported it forward to
79d3f9773c58d6fd7113871362687d8cfc0b1a59, to save someone else the
trouble. It works for me, but that's all the testing I've done.
Tim
--
Tim Stoakes
---
notmuch-new.c | 86 -
1 files changed, 85 insertions(+), 1 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..3264653 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -39,6 +39,7 @@ typedef struct {
int total_files;
int processed_files;
int added_messages;
+int 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, "flagged");
+ break;
+ case 'R': /* replied */
+ notmuch_message_add_tag (message, "answered");
+ break;
+ case 'D':
+ notmuch_message_add_tag (message, "draft");
+ break;
+ case 'S': /* seen */
+ seen = TRUE;
+ break;
+ case 'T': /* trashed */
+ notmuch_message_add_tag (message, "deleted");
+ break;
+ case 'P': /* passed */
+ notmuch_message_add_tag (message, "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)
@@ -222,6 +277,7 @@ add_files_recursive (notmuch_database_t *notmuch,
notmuch_filenames_t *db_subdirs = NULL;
struct stat st;
notmuch_bool_t is_maildir, new_directory;
+int maildir_detected = -1;
if (stat (path, &st)) {
fprintf (stderr, "Error reading directory %s: %s\n",
@@ -301,6 +357,28 @@ add_files_recursive (notmuch_database_t *notmuch,
continue;
}
+ /* If this directory is a Maildir folder, we need to
+* ignore any subdirectories marked tmp/, and scan for
+* Maildir attributes on messages contained in the sub-
+* directories 'new' and 'cur'. */
+ if (maildir_detected != 0 &&
+ entry->d_type == DT_DIR &&
+ ((strcmp (entry->d_name, "tmp") == 0) ||
+(strcmp (entry->d_name, "new") == 0) ||
+(strcmp (entry->d_name, "cur") == 0))) {
+
+if (maildir_detected == -1) {
+ maildir_detected = _entries_resemble_maildir(fs_entries, num_fs_entries);
+}
+if (maildir_detected == 1) {
+ if (strcmp (entry->d_name, "tmp") == 0) {
+continue;
+ } else {
+state->tag_maildir = TRUE;
+ }
+}
+ }
+
next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
status = add_files_recursive (notmuch, next, state);
if (status && ret == NOTMUCH_STATUS_SUCCESS)
@@ -412,7 +490,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);
+ }
Re: [notmuch] viewing text/html (inline or otherwise)
On Tue, 09 Feb 2010 16:43:20 -0800, Alexander Botero-Lowry wrote: > > rendering of non-HTML messages. And I did that with the expectation that > > the code would appear again shortly with the obvious optimization to not > > do any extra work for non-HTML messages. > EBUSY... > > I'll get around to it, HEUREKA; I have just my first blue pill image in notmuch/emacs! Back to civilization. Now, if we can extend this check to also include images inline, I will be completely happy. But this is really nice already. Thanks to those involved. spaetz ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patchwork test instance
On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft wrote: > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? I'm not sure what merging patches means here; some kind of squash operation? Anyway it seemed to me that every every patch series that I looked at was broken into individual patches. Maybe I am just unlucky, or does patchwork really not understand the concept of series of patches in a thread? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patchwork test instance
On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft wrote: > > http://patchwork.madduck.net/project/notmuch/list/ now exists. > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? As long as patches aren't being marked as "rejected" or "superseded", I don't think it will be that useful in the long run. If it were actually maintained by a few people, this would probably be different. The alternative I can see is that we create a web page of patches based on carls notmuch tags (the tagging scheme he uses is unknown to me though). Something like: "notmuch dump tag:notmuch and tag:patch" could be used to construct a list of "accepted", "willnottakeit","superseded" and "pending" lists or whatever. If that list were made accessible somewhere, this would be super useful. At least it would help me see whether Carl just hasn't gotten around to including my "press 'd' for delete" patch or whether he is not interested in merging it. :) Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] hello, 'automated' tagging, synchronisation
Hello. I've been trying out notmuch for a few days, so far it looks very
useful. Thank you to all those who have participated in implementing
it. I have a couple of questions:
1. How do others add some 'automatic' tagging of new messages? At the
moment I'm using a script[1] which tags messages after running
`notmuch new`. This passes over the same data multiple times, which
seems wasteful but may be inevitable. Combined with a small amount of
lisp...
(setq notmuch-folder-list '("mine" "inbox" "rss" "unread"
"os-xen" "os-discuss" "os-laptop" "os-network"
"xen-changelog" "xen-devel" "xen-users"
"list/fork" "list/interesting-people" "list/sun-alumni"
"list/notmuch"))
(setq notmuch-folders (mapcar
'(lambda (f) (cons f (concat "tag:" f " AND tag:unread")))
notmuch-folder-list))
...things mostly work out.
2. Sometimes it's useful to use another computer. Having the Maildir
folders duplicated there is simple (already using offlineimap), as is
building the search database. Missing are the tags, particularly if
they were hand applied. So far my (unimplemented) solution for this
is to dump/restore the tags and store the dump under version
control. Moving from one computer to another (which I don't do very
often) would involve:
a$ notmuch dump >tags
a$ git commit tags
a$ git push
b$ git pull
b$ notmuch restore tags
With appropriate amounts of conflict resolution should I update the
tags on both a and b.
What does everyone else do about this?
Footnotes:
[1] http://dme.org/tmp/run-notmuch
dme.
--
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] wiki push broken
git push: ... Total 3 (delta 2), reused 0 (delta 0) error: unpack failed: unpack-objects abnormal exit To git://notmuchmail.org/git/notmuch-wiki ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'git://notmuchmail.org/git/notmuch-wiki' - This was my test push, certainly nothing that triggers disallowed things: --- a/index.mdwn +++ b/index.mdwn +## Website + This wiki is maintained using [ikiwiki](http://ikiwiki.info). You can pull and push changes using the following URL (no authentication necessary): ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
--- notmuch.el |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index c0bb552..bd721a0 100644 --- a/notmuch.el +++ b/notmuch.el @@ -816,7 +816,13 @@ before the delimiter marking the beginning of the body." (overlay-put (make-overlay (point) (re-search-forward ":")) 'face 'message-header-name) (overlay-put (make-overlay (point) (re-search-forward ".*$")) - 'face 'message-header-other))) + 'face 'message-header-other)) + (if (looking-at "[Dd]ate:") + (progn + (overlay-put (make-overlay (point) (re-search-forward ":")) +'face 'message-header-name) + (overlay-put (make-overlay (point) (re-search-forward ".*$")) +'face 'message-header-other (defun notmuch-show-markup-header (message-begin depth) "Buttonize and decorate faces in a message header. -- 1.6.6.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > [Patch to fontify date] You do realize that your patch is identical to the one in id:874omet1su@servo.finestructure.net (Jan 22)? :-) Applying this would be nice in any case, Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 12:55:49 +0100, "Sebastian Spaeth" wrote: > On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > > [Patch to fontify date] > > You do realize that your patch is identical to the one in > id:874omet1su@servo.finestructure.net (Jan 22)? :-) I didn't! My apologies to Jameson. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Icon
After my "pacman" icon (http://img194.imageshack.us/img194/2015/notmuchpacman.png) was not appreciated due to a possible "eating mail" analogy :-), I quickly hacked together another (public domain) licensed icon based on some clipart from openclipart.org. This one clearly shows that you have not much mail: http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuch.png (svg is also there) I am not saying I like it a lot, but I needed *some* icon besides the standard emacs icon in my toolbar to launch notmuch. I hope someone finds it useful. spaetz ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Icon
As much as I hate replying to myself and spamming this list, some might actually prefer a black-and-white version of a notmuch icon based on the scales of justice :-). Sorry, I won't post about this anymore. http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuchscales_alt.png (svg here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/) <>___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] hello, 'automated' tagging, synchronisation
Hi David, On Wed, 10 Feb 2010 11:06:13 +, David Edmondson wrote: > 2. ... So far my (unimplemented) solution for this >is to dump/restore the tags and store the dump under version >control. Moving from one computer to another (which I don't do very >often) would involve: > a$ notmuch dump >tags > a$ git commit tags > a$ git push > b$ git pull > b$ notmuch restore tags >With appropriate amounts of conflict resolution should I update the >tags on both a and b. This seems to be the going solution. However, if you have a stable connection and password-free ssh access to your home computer (as I do, from my work computer) I've had good luck just using the emacs client remotely, without even having notmuch installed on the second machine, by pointing the emacs variable `notmuch-command' to a shell script which, essentially, runs the following: ssh u...@host /usr/local/bin/notmuch $@ The script is a bit more complicated, and it requires a very tiny patch to notmuch.el (no effect on local usage, I posted it on the list somewhere). But if you have a fast, stable connection, and you make use of an open ssh connection, it's almost as fast as local use, and doesn't require dumping back and forth. Problem: It can't at the moment handle attachments and, I imagine, the new html-inlining, which both use emacs code that refers to (insert-file-contents). One alternative would be to replace the (insert-file-contents) calls with TRAMP calls: (insert-file-contents (concat "/ssh:" host ":" file)) I'm also working on a trivial, but abstractable, solution that adds something like "notmuch show --raw-file," which could replace all of those emacs calls with notmuch calls, and which can therefore use the hacked-up client-server model. In other words, the latter solution would work in both the local and remote case, without having to alter the emacs client. This solution is not perfect, and it might not fit your needs, but I wanted to mention it, in addition to the dumping-restoring, as something that has been working well for me for a while now, when I have to use a second computer. Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
On Thu, 31 Dec 2009 11:17:40 -0400, da...@tethera.net wrote: > From: Scott Robinson > > In the case of notmuch-show, "--format=json" also implies > "--entire-thread" as the thread structure is implicit in the emitted > document tree. > Dear Scott and other interested parties; As I play with json output a bit more, it seems like having --entire-thread optional would be useful for quite a few applications. For example, if I want to get the From address for a given message-ID, I with the current setup I have to post process the output. This is doable, but I wonder if the better option isn't to make --entire-thread optional for --format=json as well. Any thoughts? David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 12:05:02 +, David Edmondson wrote: > On Wed, 10 Feb 2010 12:55:49 +0100, "Sebastian Spaeth" > wrote: > > On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > > > [Patch to fontify date] > > > > You do realize that your patch is identical to the one in > > id:874omet1su@servo.finestructure.net (Jan 22)? :-) > > I didn't! My apologies to Jameson. No worries. Hopefully Carl will get caught up on the patch backlog soon, which will probably help reduce duplicate efforts. This is probably a good argument for having a more easily browsable patch queue, so people can see what's already in there before the put in too much work. jamie. pgprxExg7LplE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] notmuch.el patch for older emacs
Emacs22 lacks apply-partially and mouse-event-p, so define them if emacs version is less than 23. With this change, I was able to begin using notmuch in emacs22. apply-partially cribbed from http://notmuchmail.org/pipermail/notmuch/2009/000889.html diff --git a/notmuch.el b/notmuch.el index 97914f2..03b17f6 100644 --- a/notmuch.el +++ b/notmuch.el @@ -51,6 +51,21 @@ (require 'mm-view) (require 'message) +;; Old emacs lacks apply-partially and mouse-event-p +(when (<= emacs-major-version 23) + (defun apply-partially (fun &rest args) + "Return a function that is a partial application of FUN to ARGS. +ARGS is a list of the first N arguments to pass to FUN. +The result is a new function which does the same as FUN, except that +the first N arguments are fixed at the values with which this function +was called." + (lexical-let ((fun fun) (args1 args)) +(lambda (&rest args2) (apply fun (append args1 args2) + + (defun mouse-event-p (object) + "Return non-nil if OBJECT is a mouse click event." + (memq (event-basic-type object) '(mouse-1 mouse-2 mouse-3 mouse-movement + (defvar notmuch-show-mode-map (let ((map (make-sparse-keymap))) (define-key map "?" 'notmuch-help) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
Excerpts from David Bremner's message of Wed Feb 10 07:51:47 -0600 2010: > Dear Scott and other interested parties; > > As I play with json output a bit more, it seems like having > --entire-thread optional would be useful for quite a few applications. > For example, if I want to get the From address for a given message-ID, I > with the current setup I have to post process the output. This is > doable, but I wonder if the better option isn't to make --entire-thread > optional for --format=json as well. > > Any thoughts? I made --entire-thread forced becuase it kept the JSON patch minimal. The way the thread structure is calculated is closely tied into the message tree recursion. It would have required a much more significant refactoring to get both ways; and, I wanted the patch to have as few barriers to being merged. However, as patch still hasn't been merged and probably needs to be rebased, there doesn't seem to be any good reason anymore to avoid the work. Except, I can't do it. As I noted in an earlier e-mail, I have to abandon this piece of code. I'm a bit busy backpacking through Central America. :-) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Icon
On Wed, 10 Feb 2010 13:46:11 +0100, "Sebastian Spaeth" wrote: > As much as I hate replying to myself and spamming this list, some might > actually prefer a black-and-white version of a notmuch icon based on the > scales of justice :-). Sorry, I won't post about this anymore. No apology necessary, Sebastian! I really appreciate your creative contributions here! > http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuchscales_alt.png > http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/) Of everything proposed so far, this one is my favorite. The black-and-white styling captures the minimal look I wanted, and I think the "lighter than nothing" humor of these scales is more clear than the perhaps-too-subtle "arrow pointing at zero" of the previous scale. This one is also fairly usable at the 16x16 size necessary for a web icon. Here's one attempt at that, (with an arbitrary color thrown in for the background). Let me know what you think. (I definitely want to replace the current ikiwiki icon we have---not that I have anything against ikiwiki, but if we're going to be shipping imagery, it should be our own). -Carl PS. Attaching this image made me explore the handling of image attachments in the notmuch-emacs client a bit. I'll write up my discoveries in a separate mail. pgp6mhNqnG9WV.pgp Description: PGP signature <>___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] emacs: On getting support for inline images
For a while I've seen that I can very conveniently deal with attachments such as PDF files or even OpenOffice (or PowerPoint) presentations with the notmuch/emacs client. I simply hit 'v' and an external viewer comes up with the attached file. That's all very nice. But strangely, I've also noticed that attached images don't get the same treatment. I investigated a bit and discovered that the images are being rendered within emacs and inside of a temporary buffer that is being used by the function invoked by 'v'. Before this function returns, the temporary buffer including the nicely inline-rendered image is being killed. (And I suspect the exact same thing is happening with encrypted messages where hitting 'v' gets emacs to prompt for the passphrase, but then nothing is displayed to the user.) I was able to get images working by customizing the mm-inline-media-tests variable. I removed the image/png clause from the value, and now when I hit 'v' I get a nice, external image viewer as configured in /etc/mailcap, etc. Here are some ideas for possible (and independent) fixes: 1. With the current setup, we know we are using a temporary buffer that the user won't see, so notmuch could temporarily set mm-inline-media-tests to nil forcing everything to use external viewers when the user presses 'v'. 2. The original presentation of Mime parts could examine mm-inline-media-tests and directly render anything possible within the original presentation of the message. This would allow images to be viewed directly without requiring the user to press 'v'. And the user could configure this existing variable to control what content is displayed inline. 3. We could move away from these various mm- functions for displaying MIME parts and simply add functionality to the notmuch command line for extracting individual MIME parts from messages, (which is something that a non-emacs client will likely want anyway). Then we can use the lower-level functions to display things directly. (For example, displaying an image looks as simple as calling the create-image and put-image functions). Anyway, there's a lot that can be done here to make the presentation much more usable. And of course, I'll always be glad for any help! -Carl pgpiehNSA73ZT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote:
> Here are some ideas for possible (and independent) fixes:
>
> 1. With the current setup, we know we are using a temporary buffer that
>the user won't see, so notmuch could temporarily set
>mm-inline-media-tests to nil forcing everything to use external
>viewers when the user presses 'v'.
Below is a patch to implement this piece.
It seems to do the trick so that I can now actually view image
attachments with 'v' (hurrah!). So I think I'll push this now.
-Carl
PS. I know that attaching the output of "git format-patch" to a message
like this isn't the "git way". (That is, you won't get the right result
by simply piping this message to "git am".) But I really wish it
were. It seems I often write code in response to an email message and I
often want to reply to that *message* and incidentally provide a
patch. The git way, with the commit message in the subject and the first
part of the body seems backwards to me, (as far as the conversation is
concerned).
PPS. If I did want to construct this message in the "git way", but
without using git-send-mail, I know how to construct the subject line
and how to put explanatory text like this below the separator. But what
am I supposed to do with the commit identifier that appears in an mbox
"From" line in the format-patch output? I assume this is required for
"git am -3" to work, but where can I put it in an email message?
pgp5XiXhNv2N3.pgp
Description: PGP signature
>From 2174adf374370135061bd80db21cbd43bbac95ab Mon Sep 17 00:00:00 2001
From: Carl Worth
Date: Wed, 10 Feb 2010 12:40:47 -0800
Subject: [PATCH] notmuch.el: Handle attached images via an external viewer.
We temporarily override the mm-inline-media-tests variable so that the
only parts inserted into the temporary buffer (and lost) are those
parts that the user has already seen in the notmuch-show buffer.
Anything else, (such as images), will now be left to be handled via
mailcap, just like other attachment types.
---
notmuch.el | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index b909567..040997e 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -327,7 +327,22 @@ buffer."
"Use external viewers to view all attachments from the current message."
(interactive)
(with-current-notmuch-show-message
- (mm-display-parts (mm-dissect-buffer
+ ; We ovverride the mm-inline-media-tests to indicate which message
+ ; parts are already sufficiently handled by the original
+ ; presentation of the message in notmuch-show mode. These parts
+ ; will be inserted directly into the temporary buffer of
+ ; with-current-notmuch-show-message and silently discarded.
+ ;
+ ; Any MIME part not explicitly mentioned here will be handled by an
+ ; external viewer as configured in the various mailcap files.
+ (let ((mm-inline-media-tests '(
+ ("text/.*" ignore identity)
+ ("application/pgp-signature" ignore identity)
+ ("multipart/alternative" ignore identity)
+ ("multipart/mixed" ignore identity)
+ ("multipart/related" ignore identity)
+ )))
+ (mm-display-parts (mm-dissect-buffer)
(defun notmuch-foreach-mime-part (function mm-handle)
(cond ((stringp (car mm-handle))
--
1.6.5.7
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 77f3a357ba41dcc33abbc63c39b77ae4e6636099
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 77f3a357ba41dcc33abbc63c39b77ae4e6636099 (commit) from 544d7f7f237949acc979232ed754eca3918645eb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 77f3a357ba41dcc33abbc63c39b77ae4e6636099 Author: Carl Worth Date: Wed Feb 10 12:56:33 2010 -0800 Add an actual mail-related favicon. This replaces the default ikiwiki favicon. Thanks to "Sebastian Spaeth" for the public-domain artwork with the original SVG available here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/ --- Summary of changes: favicon.ico | Bin 371 -> 646 bytes 1 files changed, 0 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. e383202eb78704d9ab85c1818a328cac62bad80a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via e383202eb78704d9ab85c1818a328cac62bad80a (commit) from 77f3a357ba41dcc33abbc63c39b77ae4e6636099 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit e383202eb78704d9ab85c1818a328cac62bad80a Author: Carl Worth Date: Wed Feb 10 13:00:07 2010 -0800 favicon: Revert to the original transparent background. I had originally flattened the image with the out-dated expectation that we couldn't do a favicon with alpha in it. I was glad to find I was wrong on that point. --- Summary of changes: favicon.ico | Bin 646 -> 587 bytes 1 files changed, 0 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 2c82f53ac040c716ae4d2198bba85a4a9b805ae2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 (commit) from e383202eb78704d9ab85c1818a328cac62bad80a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 Author: Carl Worth Date: Wed Feb 10 13:05:11 2010 -0800 Add a website header. Mostly just testing a push to the git-daemon for Sebastian. --- Summary of changes: index.mdwn |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 (commit) from 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 Author: Carl Worth Date: Wed Feb 10 13:27:29 2010 -0800 Add publically-available "private" key for anongit user This key can be used to push via ssh to: anon...@git.notmuchmail.org:/git/notmuch-wiki --- Summary of changes: anongit.key | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100644 anongit.key hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 (commit) from 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 Author: Carl Worth Date: Wed Feb 10 13:33:00 2010 -0800 Mention the notmuch-commits mailing list. It's recently been turned on, so we might as well advertise it. --- Summary of changes: index.mdwn |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 6a7510bbd2dbf043516906e9570f49d1e03ade1f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 6a7510bbd2dbf043516906e9570f49d1e03ade1f (commit) from 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 6a7510bbd2dbf043516906e9570f49d1e03ade1f Author: Carl Worth Date: Wed Feb 10 13:34:41 2010 -0800 Add PNG and SVG versions of the new "scales" logo. Great thanks to "Sebastian Spaeth" for the public-domain artwork with the original SVG available here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/ --- Summary of changes: notmuch-logo.png | Bin 0 -> 5914 bytes notmuch-logo.svg | 563 ++ 2 files changed, 563 insertions(+), 0 deletions(-) create mode 100644 notmuch-logo.png create mode 100644 notmuch-logo.svg hooks/post-receive -- The notmuchmail.org wiki. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Sorry about the SCM spam
Those messages were intended to go to the notmuch-comm...@notmuchmail.org list, but I obviously type the wrong address. Things should be back to normal now. -Carl pgpOkkeJ5mPII.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > For a while I've seen that I can very conveniently deal with attachments > such as PDF files or even OpenOffice (or PowerPoint) presentations with > the notmuch/emacs client. I simply hit 'v' and an external viewer comes > up with the attached file. That's all very nice. > Yeah, though it would b enice if we had more fine-grained control over it, like allowing you to save a file regardless of mm-* thinks it should get to display it or not. > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that >the user won't see, so notmuch could temporarily set >mm-inline-media-tests to nil forcing everything to use external >viewers when the user presses 'v'. > I think this is a crappy, but perfectly fine temporary fix. > 2. The original presentation of Mime parts could examine >mm-inline-media-tests and directly render anything possible within >the original presentation of the message. This would allow images to >be viewed directly without requiring the user to press 'v'. And the >user could configure this existing variable to control what content >is displayed inline. > Yes, I think some kind of mapping of interesting parts in the message to the mm-dissect-buffer parts and extending the text/html only inliner to also inline those interesting parts is the right thing (tm). Which points out a huge issue in my current inlining code, the parts aren't actually mapped, we're basically counting on the coincidence that the parts are in the correct place when we do the inlining, and that seems to basically work. That being said, it's the cause of some messages occasionally giving you a save dialog, or failing to be parsed correctly. > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). > Just talking about this on IRC. I think this is the wrong approach but with some right bits. notmuch cli needs to support saving parts. Period. but mm-* is a very complex and magical library happily used by (almost?) all the emacs mailers. It does a nice job once you learn how to wield its magic correctly (and indeed, one of our bigger problems is the thread-view is something it wasn't really designed for, so we just need to figure out the best-practice for working around that). mm-* should continue to be used, and we need to figure out the right technique for mapping between parts mentioned in the output of notmuch show and the actual parts in the mm-dissect-buffer output. I want to work on this, but I've been kind of busy and not felt like hacking elisp lately, so hopefilly that'll turn around :/ alex ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patchwork test instance
also sprach David Bremner [2010.02.10.2149 +1300]: > I'm not sure what merging patches means here; some kind of squash > operation? Anyway it seemed to me that every every patch series > that I looked at was broken into individual patches. Maybe I am > just unlucky, or does patchwork really not understand the concept > of series of patches in a thread? I don't think it does, this is what bundles are for, but these need to be created manually at the moment. Patch series are pretty easy to detect, so maybe the bundle could be automatically generated. http://lists.ozlabs.org/pipermail/patchwork/2010-February/000226.html -- martin | http://madduck.net/ | http://two.sentenc.es/ because light travels faster than sound, some people appear to be intelligent, until you hear them speak. spamtraps: madduck.bo...@madduck.net ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > Here are some ideas for possible (and independent) fixes: > > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). I really think that this (#3) is the way to go, going forward. First, it frees us up from the various slownesses and eccentricities of the mm- modes. Second, and more importantly, it makes it a *lot* easier for other clients to play, for the remote use of the existing emacs client, and for scripted command-line usage (e.g. put all the attached vcards in your maildir into a directory). I've been playing around with this a bit, for my own purposes, already. Unfortunately, my autodidact's c code is probably all sorts of wrong, and I wouldn't want to subject anyone to it. But it does seem like the way to go, and I'd be very happy to help out with any testing, if anyone goes forwad with this. Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] patchwork test instance
also sprach Sebastian Spaeth [2010.02.10.2225 +1300]: > "notmuch dump tag:notmuch and tag:patch" could be used to construct a > list of "accepted", "willnottakeit","superseded" and "pending" lists or > whatever. If that list were made accessible somewhere, this would be > super useful. At least it would help me see whether Carl just hasn't > gotten around to including my "press 'd' for delete" patch or whether he > is not interested in merging it. :) Carl, would you consider bouncing messages to addresses like patchwork+rejec...@patchwork.notmuchmail.org? That would make it trivial for me to write glue to update patchwork automatically. -- martin | http://madduck.net/ | http://two.sentenc.es/ "es ist gut, eine sache doppelt auszudrücken und ihr einen rechten und linken fuß zu geben. auf einem bein kann die wahrheit zwar stehen; mit zweien aber wird sie gehen und herumkommen." -- friedrich nietzsche spamtraps: madduck.bo...@madduck.net ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:54:52 -0800, Carl Worth wrote: > PS. I know that attaching the output of "git format-patch" to a message > like this isn't the "git way". (That is, you won't get the right result > by simply piping this message to "git am".) But I really wish it > were. It seems I often write code in response to an email message and I > often want to reply to that *message* and incidentally provide a > patch. The git way, with the commit message in the subject and the first > part of the body seems backwards to me, (as far as the conversation is > concerned). Hi Carl, this is what scissors line was designed for. At least according to git-mailinfo(1). "git am -c" should take it into account as well. I wanted to test this with my previous patch I sent this way, but I get fatal: corrupt patch at line 27. So I do not know whether it really works. > PPS. If I did want to construct this message in the "git way", but > without using git-send-mail, I know how to construct the subject line > and how to put explanatory text like this below the separator. But what > am I supposed to do with the commit identifier that appears in an mbox > "From" line in the format-patch output? I assume this is required for > "git am -3" to work, but where can I put it in an email message? I'm not sure whether From line is used for 3 way merge. It seems that mails produced by git send-email do not contain it. I think that the index lines just after diff --git could be sufficient for 3 way merge. Is it correct? Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > I investigated a bit and discovered that the images are being rendered > within emacs and inside of a temporary buffer that is being used by the > function invoked by 'v'. Before this function returns, the temporary > buffer including the nicely inline-rendered image is being killed. (And > I suspect the exact same thing is happening with encrypted messages > where hitting 'v' gets emacs to prompt for the passphrase, but then > nothing is displayed to the user.) > > I was able to get images working by customizing the > mm-inline-media-tests variable. I removed the image/png clause from the > value, and now when I hit 'v' I get a nice, external image viewer as > configured in /etc/mailcap, etc. > > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that >the user won't see, so notmuch could temporarily set >mm-inline-media-tests to nil forcing everything to use external >viewers when the user presses 'v'. This would leave encrypted messages in a weird spot. What external viewer would you want to be launched when you press 'v' on an encrypted message? I'd like it to be emacs myself, and even better I want it to be in notmuch/mml-mode so I can reply to it and get quoting. Although this option seems like the easiest solution, it avoids the problem, and unfortunately not very well. Emacs can display images and PDFs fine too, it just can't do openoffice documents, yet ;) > 2. The original presentation of Mime parts could examine >mm-inline-media-tests and directly render anything possible within >the original presentation of the message. This would allow images to >be viewed directly without requiring the user to press 'v'. And the >user could configure this existing variable to control what content >is displayed inline. This seems like the right way to handle things in the emacs mode. > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). I would think that the mm functions are probably pretty battle-tested and have been in a lot of very careful honing over the years. They probably do the right thing, and do it well because a lot of work has gone into getting them right. I'm sure there is a big here and there, but still it seems like it would be a shame not to use something that has a pretty full feature-set. On the other-hand, I see your point about non-emacs clients, and the command-line having the ability to parse our MIME parts. Perhaps there is room for both to play? micah pgphpQ8bRiNQ6.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] patchwork test instance
also sprach martin f krafft [2010.02.02.1131 +1300]: > I investigated some patch/issue trackers over the weekend. Here's my > summary/reply. > > The executive summary is that > http://patchwork.madduck.net/project/notmuch/list/ now exists. > I have not really used it for anything real, so if some of you feel > inclined to give it a shot, sign up and triage away! Feedback > welcome. Are people actually using it? I know that merging patches is impossible, and that sucks, but otherwise: is this something to keep around, or should I take the site offline again? -- martin | http://madduck.net/ | http://two.sentenc.es/ "time flies like an arrow. fruit flies like a banana." -- groucho marx spamtraps: madduck.bogus at madduck.net -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100210/d5dc4c1c/attachment.pgp>
[notmuch] viewing text/html (inline or otherwise)
On Tue, 09 Feb 2010 16:43:20 -0800, Alexander Botero-Lowry wrote: > > I'll get around to it, I continue to run ancient notmuch with my patch > still in place though because I find it basically unuseable without it, > so I hope to get some free time to pull the change back up and add the > optimization (which is to check the type of the mime part before trying > to do an mm-display-parts on it, so that you save the time of the > dissection if it's not needed). > I have just pulled the latest from git.notmuchmail.org (which includes your reworked inline-html patch). So far it seems to be working great. Thanks! Alex -- Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
[notmuch] viewing text/html (inline or otherwise)
On Tue, 09 Feb 2010 16:43:20 -0800, Alexander Botero-Lowry wrote: > > rendering of non-HTML messages. And I did that with the expectation that > > the code would appear again shortly with the obvious optimization to not > > do any extra work for non-HTML messages. > EBUSY... > > I'll get around to it, HEUREKA; I have just my first blue pill image in notmuch/emacs! Back to civilization. Now, if we can extend this check to also include images inline, I will be completely happy. But this is really nice already. Thanks to those involved. spaetz
[notmuch] patchwork test instance
On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft wrote: > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? I'm not sure what merging patches means here; some kind of squash operation? Anyway it seemed to me that every every patch series that I looked at was broken into individual patches. Maybe I am just unlucky, or does patchwork really not understand the concept of series of patches in a thread? d
[notmuch] patchwork test instance
On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft wrote: > > http://patchwork.madduck.net/project/notmuch/list/ now exists. > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? As long as patches aren't being marked as "rejected" or "superseded", I don't think it will be that useful in the long run. If it were actually maintained by a few people, this would probably be different. The alternative I can see is that we create a web page of patches based on carls notmuch tags (the tagging scheme he uses is unknown to me though). Something like: "notmuch dump tag:notmuch and tag:patch" could be used to construct a list of "accepted", "willnottakeit","superseded" and "pending" lists or whatever. If that list were made accessible somewhere, this would be super useful. At least it would help me see whether Carl just hasn't gotten around to including my "press 'd' for delete" patch or whether he is not interested in merging it. :) Sebastian
[notmuch] hello, 'automated' tagging, synchronisation
Hello. I've been trying out notmuch for a few days, so far it looks very
useful. Thank you to all those who have participated in implementing
it. I have a couple of questions:
1. How do others add some 'automatic' tagging of new messages? At the
moment I'm using a script[1] which tags messages after running
`notmuch new`. This passes over the same data multiple times, which
seems wasteful but may be inevitable. Combined with a small amount of
lisp...
(setq notmuch-folder-list '("mine" "inbox" "rss" "unread"
"os-xen" "os-discuss" "os-laptop" "os-network"
"xen-changelog" "xen-devel" "xen-users"
"list/fork" "list/interesting-people" "list/sun-alumni"
"list/notmuch"))
(setq notmuch-folders (mapcar
'(lambda (f) (cons f (concat "tag:" f " AND tag:unread")))
notmuch-folder-list))
...things mostly work out.
2. Sometimes it's useful to use another computer. Having the Maildir
folders duplicated there is simple (already using offlineimap), as is
building the search database. Missing are the tags, particularly if
they were hand applied. So far my (unimplemented) solution for this
is to dump/restore the tags and store the dump under version
control. Moving from one computer to another (which I don't do very
often) would involve:
a$ notmuch dump >tags
a$ git commit tags
a$ git push
b$ git pull
b$ notmuch restore tags
With appropriate amounts of conflict resolution should I update the
tags on both a and b.
What does everyone else do about this?
Footnotes:
[1] http://dme.org/tmp/run-notmuch
dme.
--
David Edmondson, http://dme.org
[notmuch] wiki push broken
git push: ... Total 3 (delta 2), reused 0 (delta 0) error: unpack failed: unpack-objects abnormal exit To git://notmuchmail.org/git/notmuch-wiki ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'git://notmuchmail.org/git/notmuch-wiki' - This was my test push, certainly nothing that triggers disallowed things: --- a/index.mdwn +++ b/index.mdwn +## Website + This wiki is maintained using [ikiwiki](http://ikiwiki.info). You can pull and push changes using the following URL (no authentication necessary):
[notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
--- notmuch.el |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index c0bb552..bd721a0 100644 --- a/notmuch.el +++ b/notmuch.el @@ -816,7 +816,13 @@ before the delimiter marking the beginning of the body." (overlay-put (make-overlay (point) (re-search-forward ":")) 'face 'message-header-name) (overlay-put (make-overlay (point) (re-search-forward ".*$")) - 'face 'message-header-other))) + 'face 'message-header-other)) + (if (looking-at "[Dd]ate:") + (progn + (overlay-put (make-overlay (point) (re-search-forward ":")) +'face 'message-header-name) + (overlay-put (make-overlay (point) (re-search-forward ".*$")) +'face 'message-header-other (defun notmuch-show-markup-header (message-begin depth) "Buttonize and decorate faces in a message header. -- 1.6.6.1
[notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > [Patch to fontify date] You do realize that your patch is identical to the one in id:874omet1su.fsf at servo.finestructure.net (Jan 22)? :-) Applying this would be nice in any case, Sebastian
[notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 12:55:49 +0100, "Sebastian Spaeth" wrote: > On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > > [Patch to fontify date] > > You do realize that your patch is identical to the one in > id:874omet1su.fsf at servo.finestructure.net (Jan 22)? :-) I didn't! My apologies to Jameson.
[notmuch] Icon
After my "pacman" icon (http://img194.imageshack.us/img194/2015/notmuchpacman.png) was not appreciated due to a possible "eating mail" analogy :-), I quickly hacked together another (public domain) licensed icon based on some clipart from openclipart.org. This one clearly shows that you have not much mail: http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuch.png (svg is also there) I am not saying I like it a lot, but I needed *some* icon besides the standard emacs icon in my toolbar to launch notmuch. I hope someone finds it useful. spaetz
[notmuch] Icon
As much as I hate replying to myself and spamming this list, some might actually prefer a black-and-white version of a notmuch icon based on the scales of justice :-). Sorry, I won't post about this anymore. http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuchscales_alt.png (svg here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/) -- next part -- A non-text attachment was scrubbed... Name: notmuchscales_alt.png Type: image/png Size: 2192 bytes Desc: icon proposal URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100210/66f2e8d2/attachment-0001.png>
[notmuch] hello, 'automated' tagging, synchronisation
Hi David, On Wed, 10 Feb 2010 11:06:13 +, David Edmondson wrote: > 2. ... So far my (unimplemented) solution for this >is to dump/restore the tags and store the dump under version >control. Moving from one computer to another (which I don't do very >often) would involve: > a$ notmuch dump >tags > a$ git commit tags > a$ git push > b$ git pull > b$ notmuch restore tags >With appropriate amounts of conflict resolution should I update the >tags on both a and b. This seems to be the going solution. However, if you have a stable connection and password-free ssh access to your home computer (as I do, from my work computer) I've had good luck just using the emacs client remotely, without even having notmuch installed on the second machine, by pointing the emacs variable `notmuch-command' to a shell script which, essentially, runs the following: ssh user at host /usr/local/bin/notmuch $@ The script is a bit more complicated, and it requires a very tiny patch to notmuch.el (no effect on local usage, I posted it on the list somewhere). But if you have a fast, stable connection, and you make use of an open ssh connection, it's almost as fast as local use, and doesn't require dumping back and forth. Problem: It can't at the moment handle attachments and, I imagine, the new html-inlining, which both use emacs code that refers to (insert-file-contents). One alternative would be to replace the (insert-file-contents) calls with TRAMP calls: (insert-file-contents (concat "/ssh:" host ":" file)) I'm also working on a trivial, but abstractable, solution that adds something like "notmuch show --raw-file," which could replace all of those emacs calls with notmuch calls, and which can therefore use the hacked-up client-server model. In other words, the latter solution would work in both the local and remote case, without having to alter the emacs client. This solution is not perfect, and it might not fit your needs, but I wanted to mention it, in addition to the dumping-restoring, as something that has been working well for me for a while now, when I have to use a second computer. Best, Jesse
[notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
On Thu, 31 Dec 2009 11:17:40 -0400, david at tethera.net wrote: > From: Scott Robinson > > In the case of notmuch-show, "--format=json" also implies > "--entire-thread" as the thread structure is implicit in the emitted > document tree. > Dear Scott and other interested parties; As I play with json output a bit more, it seems like having --entire-thread optional would be useful for quite a few applications. For example, if I want to get the From address for a given message-ID, I with the current setup I have to post process the output. This is doable, but I wonder if the better option isn't to make --entire-thread optional for --format=json as well. Any thoughts? David
[notmuch] [PATCH] notmuch.el: Decorate 'Date:' headers with the message-header-other face when visible.
On Wed, 10 Feb 2010 12:05:02 +, David Edmondson wrote: > On Wed, 10 Feb 2010 12:55:49 +0100, "Sebastian Spaeth" SSpaeth.de> wrote: > > On Wed, 10 Feb 2010 11:38:54 +, David Edmondson wrote: > > > [Patch to fontify date] > > > > You do realize that your patch is identical to the one in > > id:874omet1su.fsf at servo.finestructure.net (Jan 22)? :-) > > I didn't! My apologies to Jameson. No worries. Hopefully Carl will get caught up on the patch backlog soon, which will probably help reduce duplicate efforts. This is probably a good argument for having a more easily browsable patch queue, so people can see what's already in there before the put in too much work. 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/20100210/709aa02e/attachment.pgp>
[notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
Excerpts from David Bremner's message of Wed Feb 10 07:51:47 -0600 2010: > Dear Scott and other interested parties; > > As I play with json output a bit more, it seems like having > --entire-thread optional would be useful for quite a few applications. > For example, if I want to get the From address for a given message-ID, I > with the current setup I have to post process the output. This is > doable, but I wonder if the better option isn't to make --entire-thread > optional for --format=json as well. > > Any thoughts? I made --entire-thread forced becuase it kept the JSON patch minimal. The way the thread structure is calculated is closely tied into the message tree recursion. It would have required a much more significant refactoring to get both ways; and, I wanted the patch to have as few barriers to being merged. However, as patch still hasn't been merged and probably needs to be rebased, there doesn't seem to be any good reason anymore to avoid the work. Except, I can't do it. As I noted in an earlier e-mail, I have to abandon this piece of code. I'm a bit busy backpacking through Central America. :-)
[notmuch] Icon
On Wed, 10 Feb 2010 13:46:11 +0100, "Sebastian Spaeth" wrote: > As much as I hate replying to myself and spamming this list, some might > actually prefer a black-and-white version of a notmuch icon based on the > scales of justice :-). Sorry, I won't post about this anymore. No apology necessary, Sebastian! I really appreciate your creative contributions here! > http://github.com/spaetz/notmuch-all-feature/raw/master/contrib/notmuchscales_alt.png > http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/) Of everything proposed so far, this one is my favorite. The black-and-white styling captures the minimal look I wanted, and I think the "lighter than nothing" humor of these scales is more clear than the perhaps-too-subtle "arrow pointing at zero" of the previous scale. This one is also fairly usable at the 16x16 size necessary for a web icon. Here's one attempt at that, (with an arbitrary color thrown in for the background). Let me know what you think. (I definitely want to replace the current ikiwiki icon we have---not that I have anything against ikiwiki, but if we're going to be shipping imagery, it should be our own). -Carl PS. Attaching this image made me explore the handling of image attachments in the notmuch-emacs client a bit. I'll write up my discoveries in a separate mail. -- 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/20100210/307a1148/attachment.pgp> -- next part -- A non-text attachment was scrubbed... Name: notmuch-webicon.png Type: image/png Size: 646 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100210/307a1148/attachment.png>
[notmuch] emacs: On getting support for inline images
For a while I've seen that I can very conveniently deal with attachments such as PDF files or even OpenOffice (or PowerPoint) presentations with the notmuch/emacs client. I simply hit 'v' and an external viewer comes up with the attached file. That's all very nice. But strangely, I've also noticed that attached images don't get the same treatment. I investigated a bit and discovered that the images are being rendered within emacs and inside of a temporary buffer that is being used by the function invoked by 'v'. Before this function returns, the temporary buffer including the nicely inline-rendered image is being killed. (And I suspect the exact same thing is happening with encrypted messages where hitting 'v' gets emacs to prompt for the passphrase, but then nothing is displayed to the user.) I was able to get images working by customizing the mm-inline-media-tests variable. I removed the image/png clause from the value, and now when I hit 'v' I get a nice, external image viewer as configured in /etc/mailcap, etc. Here are some ideas for possible (and independent) fixes: 1. With the current setup, we know we are using a temporary buffer that the user won't see, so notmuch could temporarily set mm-inline-media-tests to nil forcing everything to use external viewers when the user presses 'v'. 2. The original presentation of Mime parts could examine mm-inline-media-tests and directly render anything possible within the original presentation of the message. This would allow images to be viewed directly without requiring the user to press 'v'. And the user could configure this existing variable to control what content is displayed inline. 3. We could move away from these various mm- functions for displaying MIME parts and simply add functionality to the notmuch command line for extracting individual MIME parts from messages, (which is something that a non-emacs client will likely want anyway). Then we can use the lower-level functions to display things directly. (For example, displaying an image looks as simple as calling the create-image and put-image functions). Anyway, there's a lot that can be done here to make the presentation much more usable. And of course, I'll always be glad for any help! -Carl -- 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/20100210/3e96fbae/attachment.pgp>
[notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that >the user won't see, so notmuch could temporarily set >mm-inline-media-tests to nil forcing everything to use external >viewers when the user presses 'v'. Below is a patch to implement this piece. It seems to do the trick so that I can now actually view image attachments with 'v' (hurrah!). So I think I'll push this now. -Carl PS. I know that attaching the output of "git format-patch" to a message like this isn't the "git way". (That is, you won't get the right result by simply piping this message to "git am".) But I really wish it were. It seems I often write code in response to an email message and I often want to reply to that *message* and incidentally provide a patch. The git way, with the commit message in the subject and the first part of the body seems backwards to me, (as far as the conversation is concerned). PPS. If I did want to construct this message in the "git way", but without using git-send-mail, I know how to construct the subject line and how to put explanatory text like this below the separator. But what am I supposed to do with the commit identifier that appears in an mbox "From" line in the format-patch output? I assume this is required for "git am -3" to work, but where can I put it in an email message? -- 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/20100210/0e4cec01/attachment.pgp> -- next part -- A non-text attachment was scrubbed... Name: 0001-notmuch.el-Handle-attached-images-via-an-external-vi.patch Type: text/x-diff Size: 1833 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100210/0e4cec01/attachment.patch>
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 77f3a357ba41dcc33abbc63c39b77ae4e6636099
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 77f3a357ba41dcc33abbc63c39b77ae4e6636099 (commit) from 544d7f7f237949acc979232ed754eca3918645eb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 77f3a357ba41dcc33abbc63c39b77ae4e6636099 Author: Carl Worth Date: Wed Feb 10 12:56:33 2010 -0800 Add an actual mail-related favicon. This replaces the default ikiwiki favicon. Thanks to "Sebastian Spaeth" for the public-domain artwork with the original SVG available here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/ --- Summary of changes: favicon.ico | Bin 371 -> 646 bytes 1 files changed, 0 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. e383202eb78704d9ab85c1818a328cac62bad80a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via e383202eb78704d9ab85c1818a328cac62bad80a (commit) from 77f3a357ba41dcc33abbc63c39b77ae4e6636099 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit e383202eb78704d9ab85c1818a328cac62bad80a Author: Carl Worth Date: Wed Feb 10 13:00:07 2010 -0800 favicon: Revert to the original transparent background. I had originally flattened the image with the out-dated expectation that we couldn't do a favicon with alpha in it. I was glad to find I was wrong on that point. --- Summary of changes: favicon.ico | Bin 646 -> 587 bytes 1 files changed, 0 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 2c82f53ac040c716ae4d2198bba85a4a9b805ae2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 (commit) from e383202eb78704d9ab85c1818a328cac62bad80a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 Author: Carl Worth Date: Wed Feb 10 13:05:11 2010 -0800 Add a website header. Mostly just testing a push to the git-daemon for Sebastian. --- Summary of changes: index.mdwn |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 (commit) from 2c82f53ac040c716ae4d2198bba85a4a9b805ae2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 Author: Carl Worth Date: Wed Feb 10 13:27:29 2010 -0800 Add publically-available "private" key for anongit user This key can be used to push via ssh to: anongit at git.notmuchmail.org:/git/notmuch-wiki --- Summary of changes: anongit.key | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100644 anongit.key hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 (commit) from 023952dcb7cbf5d4bd9c8ba2c79bac11d54af1d4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 Author: Carl Worth Date: Wed Feb 10 13:33:00 2010 -0800 Mention the notmuch-commits mailing list. It's recently been turned on, so we might as well advertise it. --- Summary of changes: index.mdwn |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] [SCM] The notmuchmail.org wiki. branch, master, updated. 6a7510bbd2dbf043516906e9570f49d1e03ade1f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The notmuchmail.org wiki.". The branch, master has been updated via 6a7510bbd2dbf043516906e9570f49d1e03ade1f (commit) from 8ac9d484a5bacbde77ea380e2eaac0d3c5a89e78 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 6a7510bbd2dbf043516906e9570f49d1e03ade1f Author: Carl Worth Date: Wed Feb 10 13:34:41 2010 -0800 Add PNG and SVG versions of the new "scales" logo. Great thanks to "Sebastian Spaeth" for the public-domain artwork with the original SVG available here: http://github.com/spaetz/notmuch-all-feature/tree/master/contrib/ --- Summary of changes: notmuch-logo.png | Bin 0 -> 5914 bytes notmuch-logo.svg | 563 ++ 2 files changed, 563 insertions(+), 0 deletions(-) create mode 100644 notmuch-logo.png create mode 100644 notmuch-logo.svg hooks/post-receive -- The notmuchmail.org wiki.
[notmuch] Sorry about the SCM spam
Those messages were intended to go to the notmuch-commits at notmuchmail.org list, but I obviously type the wrong address. Things should be back to normal now. -Carl -- 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/20100210/6ecffcd3/attachment.pgp>
[notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > For a while I've seen that I can very conveniently deal with attachments > such as PDF files or even OpenOffice (or PowerPoint) presentations with > the notmuch/emacs client. I simply hit 'v' and an external viewer comes > up with the attached file. That's all very nice. > Yeah, though it would b enice if we had more fine-grained control over it, like allowing you to save a file regardless of mm-* thinks it should get to display it or not. > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that >the user won't see, so notmuch could temporarily set >mm-inline-media-tests to nil forcing everything to use external >viewers when the user presses 'v'. > I think this is a crappy, but perfectly fine temporary fix. > 2. The original presentation of Mime parts could examine >mm-inline-media-tests and directly render anything possible within >the original presentation of the message. This would allow images to >be viewed directly without requiring the user to press 'v'. And the >user could configure this existing variable to control what content >is displayed inline. > Yes, I think some kind of mapping of interesting parts in the message to the mm-dissect-buffer parts and extending the text/html only inliner to also inline those interesting parts is the right thing (tm). Which points out a huge issue in my current inlining code, the parts aren't actually mapped, we're basically counting on the coincidence that the parts are in the correct place when we do the inlining, and that seems to basically work. That being said, it's the cause of some messages occasionally giving you a save dialog, or failing to be parsed correctly. > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). > Just talking about this on IRC. I think this is the wrong approach but with some right bits. notmuch cli needs to support saving parts. Period. but mm-* is a very complex and magical library happily used by (almost?) all the emacs mailers. It does a nice job once you learn how to wield its magic correctly (and indeed, one of our bigger problems is the thread-view is something it wasn't really designed for, so we just need to figure out the best-practice for working around that). mm-* should continue to be used, and we need to figure out the right technique for mapping between parts mentioned in the output of notmuch show and the actual parts in the mm-dissect-buffer output. I want to work on this, but I've been kind of busy and not felt like hacking elisp lately, so hopefilly that'll turn around :/ alex
[notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > Here are some ideas for possible (and independent) fixes: > > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). I really think that this (#3) is the way to go, going forward. First, it frees us up from the various slownesses and eccentricities of the mm- modes. Second, and more importantly, it makes it a *lot* easier for other clients to play, for the remote use of the existing emacs client, and for scripted command-line usage (e.g. put all the attached vcards in your maildir into a directory). I've been playing around with this a bit, for my own purposes, already. Unfortunately, my autodidact's c code is probably all sorts of wrong, and I wouldn't want to subject anyone to it. But it does seem like the way to go, and I'd be very happy to help out with any testing, if anyone goes forwad with this. Best, Jesse
[notmuch] emacs: On getting support for inline images
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > I investigated a bit and discovered that the images are being rendered > within emacs and inside of a temporary buffer that is being used by the > function invoked by 'v'. Before this function returns, the temporary > buffer including the nicely inline-rendered image is being killed. (And > I suspect the exact same thing is happening with encrypted messages > where hitting 'v' gets emacs to prompt for the passphrase, but then > nothing is displayed to the user.) > > I was able to get images working by customizing the > mm-inline-media-tests variable. I removed the image/png clause from the > value, and now when I hit 'v' I get a nice, external image viewer as > configured in /etc/mailcap, etc. > > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that >the user won't see, so notmuch could temporarily set >mm-inline-media-tests to nil forcing everything to use external >viewers when the user presses 'v'. This would leave encrypted messages in a weird spot. What external viewer would you want to be launched when you press 'v' on an encrypted message? I'd like it to be emacs myself, and even better I want it to be in notmuch/mml-mode so I can reply to it and get quoting. Although this option seems like the easiest solution, it avoids the problem, and unfortunately not very well. Emacs can display images and PDFs fine too, it just can't do openoffice documents, yet ;) > 2. The original presentation of Mime parts could examine >mm-inline-media-tests and directly render anything possible within >the original presentation of the message. This would allow images to >be viewed directly without requiring the user to press 'v'. And the >user could configure this existing variable to control what content >is displayed inline. This seems like the right way to handle things in the emacs mode. > 3. We could move away from these various mm- functions for displaying >MIME parts and simply add functionality to the notmuch command line >for extracting individual MIME parts from messages, (which is >something that a non-emacs client will likely want anyway). Then we >can use the lower-level functions to display things directly. (For >example, displaying an image looks as simple as calling the >create-image and put-image functions). I would think that the mm functions are probably pretty battle-tested and have been in a lot of very careful honing over the years. They probably do the right thing, and do it well because a lot of work has gone into getting them right. I'm sure there is a big here and there, but still it seems like it would be a shame not to use something that has a pretty full feature-set. On the other-hand, I see your point about non-emacs clients, and the command-line having the ability to parse our MIME parts. Perhaps there is room for both to play? micah -- 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/20100210/8ec7b751/attachment-0001.pgp>
