[PATCH] emacs: create patch filename from subject for inline patch fake parts
Shameless promotion of own patches... I suppose not many use the notmuch-wash-convert-inline-patch-to-part option, but with this patch I've actually started to like it better. An actual patch name from subject instead of "inline patch". As I said, the lisp is less than perfect here, but this is still better than what's existing. Any comments? BR, Jani. On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula wrote: > Use the mail subject line for creating a descriptive filename for the wash > generated inline patch fake parts. The names are similar to the ones > created by 'git format-patch', just without the leading numbers. > > Signed-off-by: Jani Nikula > > --- > > I know notmuch-subject-to-patch-filename is totally un-lispy. Suggestions > welcome on how to make it lispy and keep it somewhat readable. > > If we later want to have a '>' counterpart to '|' to save messages to files > rather than pipe, then this could be generalized and re-used for creating > the suggested filename for that. > > I don't even use the notmuch-wash-convert-inline-patch-to-part option that > much, but having it suggest "inline patch" as filename is just ugly... > --- > emacs/notmuch-wash.el | 16 +++- > 1 files changed, 15 insertions(+), 1 deletions(-) > > diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el > index 1f420b2..755d64a 100644 > --- a/emacs/notmuch-wash.el > +++ b/emacs/notmuch-wash.el > @@ -290,6 +290,17 @@ When doing so, maintaining citation leaders in the > wrapped text." > > (defvar diff-file-header-re) ; From `diff-mode.el'. > > +(defun notmuch-subject-to-patch-filename (str) > + "Convert a typical patch mail subject line into a suitable filename." > + (let ((s str)) > +(setq s (replace-regexp-in-string "^ *\\(\\[[^]]*\\]\\)? *" "" s)) > +(setq s (replace-regexp-in-string "[. ]*$" "" s)) > +(setq s (replace-regexp-in-string "[^A-Za-z0-9._-]+" "-" s)) > +(setq s (replace-regexp-in-string "\\.+" "." s)) > +(when (> (length s) 52) > + (setq s (substring s 0 52))) > +(concat s ".patch"))) > + > (defun notmuch-wash-convert-inline-patch-to-part (msg depth) >"Convert an inline patch into a fake 'text/x-diff' attachment. > > @@ -316,7 +327,10 @@ for error." > (setq part (plist-put part :content-type "text/x-diff")) > (setq part (plist-put part :content (buffer-string))) > (setq part (plist-put part :id -1)) > - (setq part (plist-put part :filename "inline patch")) > + (setq part (plist-put part :filename > + (notmuch-subject-to-patch-filename > +(plist-get > + (plist-get msg :headers) :Subject > (delete-region (point-min) (point-max)) > (notmuch-show-insert-bodypart nil part depth)) > > -- > 1.7.5.4 >
[PATCH v2 2/2] emacs: Fix notmuch-mua-user-agent defcustom
The :options keyword is not meaningful for function type. Also, it was not
possible to enter nil value, contrary to the notmuch-mua-user-agent
defcustom documentation. Specify the alternatives using choice type, taking
nil into account.
Signed-off-by: Jani Nikula
---
emacs/notmuch-mua.el | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index b525762..7114e48 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -35,10 +35,12 @@
"Function used to generate a `User-Agent:' string. If this is
`nil' then no `User-Agent:' will be generated."
:group 'notmuch
- :type 'function
- :options '(notmuch-mua-user-agent-full
-notmuch-mua-user-agent-notmuch
-notmuch-mua-user-agent-emacs))
+ :type '(choice (const :tag "No user agent string" nil)
+(const :tag "Full" notmuch-mua-user-agent-full)
+(const :tag "Notmuch" notmuch-mua-user-agent-notmuch)
+(const :tag "Emacs" notmuch-mua-user-agent-emacs)
+(function :tag "Custom user agent function"
+ :value notmuch-mua-user-agent-full)))
(defcustom notmuch-mua-hidden-headers '("^User-Agent:")
"Headers that are added to the `message-mode' hidden headers
--
1.7.5.4
[PATCH v2 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
It was not possible to define custom filters or filter functions because the types were const. Remove const to allow editing. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 81b2605..7dd0f85 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -86,8 +86,9 @@ Finally this can be a function that will be called for each tag and should return a filter for that tag, or nil to hide the tag." :type '(choice (const :tag "All messages" nil) (const :tag "Unread messages" "tag:unread") -(const :tag "Custom filter" string) -(const :tag "Custom filter function" function)) +(string :tag "Custom filter" +:value "tag:unread") +(function :tag "Custom filter function")) :group 'notmuch) (defcustom notmuch-hello-hide-tags nil -- 1.7.5.4
[PATCH v2 0/2] emacs: trivial defcustom fixes
Hi all, v2 of a couple of defcustom fixes. Now with a default value for "Custom filter" in patch 1/2 as suggested by Dmitry. No other changes. BR, Jani. Jani Nikula (2): emacs: Fix notmuch-hello-tag-list-make-query defcustom emacs: Fix notmuch-mua-user-agent defcustom emacs/notmuch-hello.el |5 +++-- emacs/notmuch-mua.el | 10 ++ 2 files changed, 9 insertions(+), 6 deletions(-) -- 1.7.5.4
[PATCH] emacs: create patch filename from subject for inline patch fake parts
Seems like a definite improvement, but perhaps a let* instead of all of the setq's? Quoth Jani Nikula on Dec 20 at 10:05 pm: > > Shameless promotion of own patches... I suppose not many use the > notmuch-wash-convert-inline-patch-to-part option, but with this patch > I've actually started to like it better. An actual patch name from > subject instead of "inline patch". > > As I said, the lisp is less than perfect here, but this is still better > than what's existing. > > Any comments? > > > BR, > Jani. > > > On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula wrote: > > Use the mail subject line for creating a descriptive filename for the wash > > generated inline patch fake parts. The names are similar to the ones > > created by 'git format-patch', just without the leading numbers. > > > > Signed-off-by: Jani Nikula > > > > --- > > > > I know notmuch-subject-to-patch-filename is totally un-lispy. Suggestions > > welcome on how to make it lispy and keep it somewhat readable. > > > > If we later want to have a '>' counterpart to '|' to save messages to files > > rather than pipe, then this could be generalized and re-used for creating > > the suggested filename for that. > > > > I don't even use the notmuch-wash-convert-inline-patch-to-part option that > > much, but having it suggest "inline patch" as filename is just ugly... > > --- > > emacs/notmuch-wash.el | 16 +++- > > 1 files changed, 15 insertions(+), 1 deletions(-) > > > > diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el > > index 1f420b2..755d64a 100644 > > --- a/emacs/notmuch-wash.el > > +++ b/emacs/notmuch-wash.el > > @@ -290,6 +290,17 @@ When doing so, maintaining citation leaders in the > > wrapped text." > > > > (defvar diff-file-header-re) ; From `diff-mode.el'. > > > > +(defun notmuch-subject-to-patch-filename (str) > > + "Convert a typical patch mail subject line into a suitable filename." > > + (let ((s str)) > > +(setq s (replace-regexp-in-string "^ *\\(\\[[^]]*\\]\\)? *" "" s)) > > +(setq s (replace-regexp-in-string "[. ]*$" "" s)) > > +(setq s (replace-regexp-in-string "[^A-Za-z0-9._-]+" "-" s)) > > +(setq s (replace-regexp-in-string "\\.+" "." s)) > > +(when (> (length s) 52) > > + (setq s (substring s 0 52))) > > +(concat s ".patch"))) > > + > > (defun notmuch-wash-convert-inline-patch-to-part (msg depth) > >"Convert an inline patch into a fake 'text/x-diff' attachment. > > > > @@ -316,7 +327,10 @@ for error." > > (setq part (plist-put part :content-type "text/x-diff")) > > (setq part (plist-put part :content (buffer-string))) > > (setq part (plist-put part :id -1)) > > - (setq part (plist-put part :filename "inline patch")) > > + (setq part (plist-put part :filename > > + (notmuch-subject-to-patch-filename > > + (plist-get > > + (plist-get msg :headers) :Subject > > (delete-region (point-min) (point-max)) > > (notmuch-show-insert-bodypart nil part depth))
More ideas about logging.
On Sun, 18 Dec 2011 13:22:20 -0700, Tom Prince wrote: > On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner > wrote: > > The more worrying part is disk usage; the tag tree for 200k messages > > uses 400k inodes, and 836M of apparent disk usage (according to du) the > > same tags in "sup" format take 11M. Maybe this could be usefull if > > combined with some scheme to only dump tags not covered by maildir (for > > those using maildir flag synching already) > > Well, it would seem natural to re-use the nmbug logic here, and just use > a bare git repo for this. One would need a way to sync and merge the > tag-tree automatically anyway. I admit I haven't tried nmbug yet, but it > seems that nmbug, switched from sync just notmuch:: to syncing > everything but notmuch:: would be a sensible way to sync tags? I was mainly interested in if some guarantee of atomicity could be given in a simple way. The git update-index approach doesn't really make those kind of guaranteees.. Probably this is tolerable for a human initiated "dump" process; not so much for other uses. Furthermore much of the motivation for both mtimes and logging is to make incremental dumping possible in order to avoid the time to do of a full dump. This is experiment was also to see how feasible it was to insert some "mkdir+creat" in the notmuch-tag critical path. Since a few people have mentioned this, I should confess that there are (at least) 2 performance bugs lurking in nmbug that make it probably not yet suitable for large scale tag syncing. 1) I did not get the merging working with only the index, so nmbug currently makes a temporary checkout to do the merge. 2) transfering tags from the git repo to xapian is currently quite slow because it does one call to git tag for each tag, rather than constructing an input for "notmuch restore". I _think_ both of these are fixable in principle. Maybe somebody with better git internals knowledge than I would like to take a look at (1). (2) is just a SimpleMatterOfProgramming (TM). Patches, as they say, are welcome ;). d
[PATCH] notmuch: Quiet buildbot warnings.
Cast away the result of various *write functions. Provide a default
value for some variables to avoid "use before set" warnings.
---
The buildbot complains about these, though my own system (Debian
testing on amd64) does not.
lib/database.cc |2 +-
notmuch-new.c |2 +-
notmuch-show.c |2 +-
notmuch-tag.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 98f101e..f1a9dc2 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1447,7 +1447,7 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
keys = g_hash_table_get_keys (parents);
for (l = keys; l; l = l->next) {
char *parent_message_id;
- const char *parent_thread_id;
+ const char *parent_thread_id = NULL;
parent_message_id = (char *) l->data;
diff --git a/notmuch-new.c b/notmuch-new.c
index bfb4600..3512de7 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -67,7 +67,7 @@ handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+(void) write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
diff --git a/notmuch-show.c b/notmuch-show.c
index 8da3295..19fb49f 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -866,7 +866,7 @@ do_show_single (void *ctx,
while (!feof (file)) {
size = fread (buf, 1, sizeof (buf), file);
- fwrite (buf, size, 1, stdout);
+ (void) fwrite (buf, size, 1, stdout);
}
fclose (file);
diff --git a/notmuch-tag.c b/notmuch-tag.c
index 537d5a4..292c5da 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,7 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+(void) write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
--
1.7.7.3
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray wrote: > On Tue, 20 Dec 2011 08:35:42 +, David Edmondson wrote: > > On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray > > wrote: > > > > + (makunbound 'gnus-summary-buffer) ; Blech. > > > > > > This is working around a bug in gnus. I think the better solution would > > > be for gnus to fix the bug. The following patch against gnus works for > > > me. (I have tried submitting it to the gnus bug list, but have not been > > > able to check if it got through.) > > > > I wonder if `boundp' is just a typo for `bufferp'? > > I originally thought so as well, but bufferp blows up if given an > unbound variable and buffer-name blows up if given a string. When would `gnus-summary-buffer' ever be unbound?
Question : Tag mail according to it directory path ?
On Mon, 12 Dec 2011 21:59:09 +0100, emmanuel.leblond at gmail.com wrote: > > I have a 4000+ mail collection already sorted in folders. The point is I > would > like to tag those mails through the notmuch database according to those > folders. (i.g. the mails in the friend/foo directory will be tagged as friend > and foo) Hi, Emanuel. There is already the ability to search for messages by path with the "folder:" search prefix. From "notmuch help search-terms": The folder: prefix can be used to search for email message files that are contained within particular directories within the mail store. Only the directory components below the top-level mail database path are available to be searched. You can then easily apply arbitrary tags with something like: notmuch tag +foo -- folder:foo hth. 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/20111220/000261cc/attachment.pgp>
[PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 08:01:46 +, David Edmondson wrote: > >From a Carl Worth idea: add a function which will select the most > recently used notmuch buffer (search, show or hello). If no recent > buffer is found, run `notmuch'. > > It is expected that the user will global bind this command to a key > sequence. > --- Thanks Aaron & David for the explanations. I was finally able to test and byte compile the function separately (as a learning experiment). LGTM. I'd like to know how users are going to use this :) Tomi > emacs/notmuch.el | 17 + > 1 files changed, 17 insertions(+), 0 deletions(-) > > diff --git a/emacs/notmuch.el b/emacs/notmuch.el > index 2e9973e..da61aa9 100644 > --- a/emacs/notmuch.el > +++ b/emacs/notmuch.el > @@ -1055,6 +1055,23 @@ current search results AND that are tagged with the > given tag." >(interactive) >(notmuch-hello)) > > +;;;###autoload > +(defun notmuch-jump-to-recent-buffer () > + "Jump to the most recent notmuch buffer (search, show or hello). > + > +If no recent buffer is found, run `notmuch'." > + (interactive) > + (let ((last > + (loop for buffer in (buffer-list) > +if (with-current-buffer buffer > + (memq major-mode '(notmuch-show-mode > +notmuch-search-mode > +notmuch-hello-mode))) > +return buffer))) > +(if last > + (switch-to-buffer last) > + (notmuch > + > (setq mail-user-agent 'notmuch-user-agent) > > (provide 'notmuch) > -- > 1.7.7.3 Tomi
[PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 12:27:02 +0200, Tomi Ollila wrote: > I'd like to know how users are going to use this :) I use it as a way to jump back to whatever I was doing before I was distracted by something in the email I was reading.
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 03:40:44 -0500, Aaron Ecay wrote: > On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray > wrote: > > This is working around a bug in gnus. > > Arguably this is true, but the real ?bug? (conceptual error) is that the > MIME handling libraries and gnus are a little too tightly coupled. Why > should notmuch users have to load gnus (gnus-art.el does (require 'gnus), > which brings in tens of thousands of lines of Elisp)[1], or customize > gnus-* variables to use general-purpose MIME viewing, HTML rendering > facilities? I agree with this 100%. However, we should still try to use emacs coding best-practices, which means not defining variables that are defined in other packages. Unfortunately, getting the gnus folks to fix their library might take a while, so it might be okay to relax those best-practices while we wait, but we should be aware of the fact that that's what we're doing. Cheers, Chris
[PATCH 0/5] Store message modification times in the DB
Quoth David Edmondson on Dec 20 at 8:32 am: > > == Two-way "merge" from host R to host L == > > > > Per-host state: > > - last_mtime: Map from remote hosts to last sync mtime > > With the proposed changes it seems that the state required on each host > would live within the Xapian database (to be extracted with 'dump'). It certainly could. I haven't thought about how any of this would integrate with dump, or if it necessarily should. A related question is how bootstrap should work. For example, if you add another host, what's the best way to bring it up to speed without, say, overwriting your tags everywhere with your initial tags? In general, when a new message arrives, how do you get the hosts to agree on its tags and what happens if one host tags it before another host sees it? > > new_mtime = last_mtime[R] > > For msgid, mtime, tags in messages on host R with mtime >= last_mtime[R]: > > If mtime > local mtime of msgid: > > Set local tags of msgid to tags > > new_mtime = max(new_mtime, mtime) > > last_mtime[R] = new_mtime > > > > This has the advantage of keeping very little state, but the > > synchronization is also quite primitive. If two hosts change a > > message's tags in different ways between synchronizations, the more > > recent of the two will override the full set of tags on that message. > > This does not strictly require tombstones, though if you make a tag > > change and then delete the message before a sync, the tag change will > > be lost without some record of that state. > > Does this matter? If the tag on a deleted message is changed, does > anyone care? That depends on what sort of synchronization model you're expecting. If you're expecting git-style synchronization where all that matters is the state and not the order things happened in, then this is exactly what you'd expect. If you're expecting something more nuanced that knows about the order you did things in across hosts between synchronizations (which I think can only lead to more unintuitive corner-cases, but some people seem to expect), then this could be surprising. > > Also, this obviously depends heavily on synchronized clocks. > > > > > > == Three-way merge from host R to host L == > > > > Per-host state: > > - last_mtime: Map from remote hosts to last sync mtime > > - last_sync: Map from remote hosts to the tag database as of the last sync > > Any ideas where this state might be kept? It could also be stored in Xapian (in user keys or as additional message metadata). That would certainly be simplest and would avoid hairy atomicity issues. OTOH, it's not the end of the world if last_sync doesn't get updated atomically, especially if we can at least guarantee last_sync is fully updated and on disk before we update last_mtime. > > new_mtime = last_mtime[R] > > for msgid, mtime, r_tags in messages on host R with mtime >= last_mtime[R]: > > my_tags = local tags of msgid > > last_tags = last_sync[R][msgid] > > for each tag that differs between my_tags and r_tags: > > if tag is in last_tags: remove tag locally > > else: add tag locally > > last_sync[R][msgid] = tags > > new_mtime = max(new_mtime, mtime) > > Delete stale messages from last_sync[R] (using tombstones or something) > > last_mtime[R] = new_mtime > > > > This protocol requires significantly more state, but can also > > reconstruct per-tag changes. Conflict resolution is equivalent to > > what git would do and is based solely on the current local and remote > > state and the common ancestor state. This can lead to unintuitive > > results if a tag on a message has gone through multiple changes on > > both hosts since the last sync (though, I argue, there are no > > intuitive results in such situations). Tombstones are only required > > to garbage collect sync state (and other techniques could be used for > > that). This also does not depend on time synchronization (though, > > like any mtime solution, it does depend on mtime monotonicity). The > > algorithm would work equally well with sequence numbers. > > > > I tried coming up with a third algorithm that used mtimes to resolve > > tagging conflicts, but without per-tag mtimes it degenerated into the > > first algorithm. > > dme.
[PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Mon, 22 Nov 2010 11:51:04 +, David Edmondson wrote:
> >From a Carl Worth idea: Add `notmuch-jump-to-recent-buffer', which
> will select the most recently used notmuch buffer (search, show or
> hello). If no recent buffer is found, run `notmuch'.
>
> It is expected that the user will global bind this command to a key
> sequence.
> ---
See comments inline below.
> emacs/notmuch.el | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index e8d4d98..67271d1 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -962,6 +962,24 @@ current search results AND that are tagged with the
> given tag."
>(interactive)
>(notmuch-hello))
>
> +;;;###autoload
> +(defun notmuch-jump-to-recent-buffer ()
> + "Jump to the most recent notmuch buffer (search, show or hello).
> +
> +If no recent buffer is found, run `notmuch'."
> + (interactive)
> + (let ((last
> + (loop for buffer in (buffer-list)
> +if (progn
Are the last few lines above working... if without '(' and no
loop (nor for) function in my emacs (where notmuch loaded).
> + (set-buffer buffer)
I really like Aaron's comment about with-current-buffer...
> + (or (eq major-mode 'notmuch-show-mode)
> + (eq major-mode 'notmuch-search-mode)
> + (eq major-mode 'notmuch-hello-mode)))
... memq is also nice; in case used the list should be done beforehand with
(let* ...
> +return buffer)))
> +(if last
> + (switch-to-buffer last)
> + (notmuch
> +
> (setq mail-user-agent 'notmuch-user-agent)
>
> (provide 'notmuch)
> --
> 1.7.2.3
>
Tomi
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 14:33:01 +, David Edmondson wrote: > On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray > wrote: > > On Tue, 20 Dec 2011 08:35:42 +, David Edmondson wrote: > > > On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray > > > wrote: > > > > > + (makunbound 'gnus-summary-buffer) ; Blech. > > > > > > > > This is working around a bug in gnus. I think the better solution would > > > > be for gnus to fix the bug. The following patch against gnus works for > > > > me. (I have tried submitting it to the gnus bug list, but have not been > > > > able to check if it got through.) > > > > > > I wonder if `boundp' is just a typo for `bufferp'? > > > > I originally thought so as well, but bufferp blows up if given an > > unbound variable and buffer-name blows up if given a string. > > When would `gnus-summary-buffer' ever be unbound? In the optimal situation where we were able to use mm-decode without requiring gnus.el, then gnus-summary-buffer would be unbound. Cheers, Chris
[PATCH] emacs: Don't signal an error when reaching the end of the search results.
With the default configuration ('space' moves through the messages
matching the search and back to the results index at the end) it's
unnecessary to signal an error when the last message has been read, as
this is the common case.
Moreover, it's very annoying when `debug-on-error' is t.
---
emacs/notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 675a110..2e9973e 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -438,7 +438,7 @@ Complete list of currently available key bindings:
"*")
32 nil nil t))
crypto-switch)
- (error "End of search results"
+ (message "End of search results."
(defun notmuch-search-reply-to-thread ( prompt-for-sender)
"Begin composing a reply to the entire current thread in a new buffer."
--
1.7.7.3
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray wrote: > > + (makunbound 'gnus-summary-buffer) ; Blech. > > This is working around a bug in gnus. I think the better solution would > be for gnus to fix the bug. The following patch against gnus works for > me. (I have tried submitting it to the gnus bug list, but have not been > able to check if it got through.) I wonder if `boundp' is just a typo for `bufferp'? More on the other comments after thought. dme. -- David Edmondson, http://dme.org
[PATCH 0/5] Store message modification times in the DB
On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements wrote: > Here are sketches for two sync algorithms with different properties. > I haven't proven these to be correct, but I believe they are. In > both, R is the remote host and L is the local host. They're both > one-way (they only update tags on L), but should be symmetrically > stable. Thanks for these. > == Two-way "merge" from host R to host L == > > Per-host state: > - last_mtime: Map from remote hosts to last sync mtime With the proposed changes it seems that the state required on each host would live within the Xapian database (to be extracted with 'dump'). > new_mtime = last_mtime[R] > For msgid, mtime, tags in messages on host R with mtime >= last_mtime[R]: > If mtime > local mtime of msgid: > Set local tags of msgid to tags > new_mtime = max(new_mtime, mtime) > last_mtime[R] = new_mtime > > This has the advantage of keeping very little state, but the > synchronization is also quite primitive. If two hosts change a > message's tags in different ways between synchronizations, the more > recent of the two will override the full set of tags on that message. > This does not strictly require tombstones, though if you make a tag > change and then delete the message before a sync, the tag change will > be lost without some record of that state. Does this matter? If the tag on a deleted message is changed, does anyone care? > Also, this obviously depends heavily on synchronized clocks. > > > == Three-way merge from host R to host L == > > Per-host state: > - last_mtime: Map from remote hosts to last sync mtime > - last_sync: Map from remote hosts to the tag database as of the last sync Any ideas where this state might be kept? > new_mtime = last_mtime[R] > for msgid, mtime, r_tags in messages on host R with mtime >= last_mtime[R]: > my_tags = local tags of msgid > last_tags = last_sync[R][msgid] > for each tag that differs between my_tags and r_tags: > if tag is in last_tags: remove tag locally > else: add tag locally > last_sync[R][msgid] = tags > new_mtime = max(new_mtime, mtime) > Delete stale messages from last_sync[R] (using tombstones or something) > last_mtime[R] = new_mtime > > This protocol requires significantly more state, but can also > reconstruct per-tag changes. Conflict resolution is equivalent to > what git would do and is based solely on the current local and remote > state and the common ancestor state. This can lead to unintuitive > results if a tag on a message has gone through multiple changes on > both hosts since the last sync (though, I argue, there are no > intuitive results in such situations). Tombstones are only required > to garbage collect sync state (and other techniques could be used for > that). This also does not depend on time synchronization (though, > like any mtime solution, it does depend on mtime monotonicity). The > algorithm would work equally well with sequence numbers. > > I tried coming up with a third algorithm that used mtimes to resolve > tagging conflicts, but without per-tag mtimes it degenerated into the > first algorithm. dme. -- David Edmondson, http://dme.org
[PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 10:02:11 +0200, Tomi Ollila wrote:
> > +(loop for buffer in (buffer-list)
> > + if (progn
>
> Are the last few lines above working... if without '(' and no
> loop (nor for) function in my emacs (where notmuch loaded).
`loop' is an emacs clone of the all singing ("It slices, it dices!")
Common Lisp `loop' macro in cl-macs.el.
dme.
--
David Edmondson, http://dme.org
[PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Mon, 19 Dec 2011 12:58:53 -0500, Aaron Ecay wrote: > (Please excuse the lack of inline comments on the patch ? the original > patch email is so old that I had deleted it from my archives!) You _deleted_ things? /me faints. > progn...set-buffer should be with-current-buffer > or...eq...eq... would be cleaner as (memq major-mode '(foo bar baz)) Good comments, thanks. Updated patch sent. dme. -- David Edmondson, http://dme.org
[PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
>From a Carl Worth idea: add a function which will select the most recently used notmuch buffer (search, show or hello). If no recent buffer is found, run `notmuch'. It is expected that the user will global bind this command to a key sequence. --- emacs/notmuch.el | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 2e9973e..da61aa9 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1055,6 +1055,23 @@ current search results AND that are tagged with the given tag." (interactive) (notmuch-hello)) +;;;###autoload +(defun notmuch-jump-to-recent-buffer () + "Jump to the most recent notmuch buffer (search, show or hello). + +If no recent buffer is found, run `notmuch'." + (interactive) + (let ((last +(loop for buffer in (buffer-list) + if (with-current-buffer buffer + (memq major-mode '(notmuch-show-mode + notmuch-search-mode + notmuch-hello-mode))) + return buffer))) +(if last + (switch-to-buffer last) + (notmuch + (setq mail-user-agent 'notmuch-user-agent) (provide 'notmuch) -- 1.7.7.3
[PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 08:01:46 +, David Edmondson wrote: > From a Carl Worth idea: add a function which will select the most > recently used notmuch buffer (search, show or hello). If no recent > buffer is found, run `notmuch'. pushed d
[PATCH v4 0/4] emacs: do not call `notmuch-hello-mode' on update
On Sun, 18 Dec 2011 04:21:17 +0400, Dmitry Kurochkin wrote: > Changes: > > v4: > > * explain why we need to properly delete editable widget fields > pushed. d
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 08:35:42 +, David Edmondson wrote: > On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray > wrote: > > > + (makunbound 'gnus-summary-buffer) ; Blech. > > > > This is working around a bug in gnus. I think the better solution would > > be for gnus to fix the bug. The following patch against gnus works for > > me. (I have tried submitting it to the gnus bug list, but have not been > > able to check if it got through.) > > I wonder if `boundp' is just a typo for `bufferp'? I originally thought so as well, but bufferp blows up if given an unbound variable and buffer-name blows up if given a string. Cheers, Chris
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray wrote:
> This is working around a bug in gnus.
Arguably this is true, but the real ?bug? (conceptual error) is that the
MIME handling libraries and gnus are a little too tightly coupled. Why
should notmuch users have to load gnus (gnus-art.el does (require 'gnus),
which brings in tens of thousands of lines of Elisp)[1], or customize
gnus-* variables to use general-purpose MIME viewing, HTML rendering
facilities?
The best GNUS-side solution would be to make mm-shr GNUS-agnostic, and
probably to introduce shr-{inhibit,blocked}-images as customizable
variables in their own right (which could inherit their values from the
gnus-* versions under the right circumstances).
I hope that the GNUS folks are receptive to this approach, but if they
aren?t I think it?s better for notmuch to not go the way of requiring
that GNUS be loaded to function.
Aaron
[1] I see that (featurep 'gnus) returns t for me, so that horse is
already out of the barn. But it isn?t something we should be
seeking to perpetuate.
--
Aaron Ecay
[PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
Tomi,
On Tue, 20 Dec 2011 10:02:11 +0200, Tomi Ollila wrote:
>
> Are the last few lines above working... if without '(' and no
> loop (nor for) function in my emacs (where notmuch loaded).
This is the `loop' macro from cl.el. It mimics a Common Lisp idiom
which, strangely enough, looks nothing like Lisp but is sort of a DSL
for specifying imperative loops. You can find the documentation by
doing C-h i (to open the Info manual in Emacs) then following the ?CL?
link.
(One of the coolest features is that it is all implemented via macros,
so the compiler automatically unrolls it into a native Lisp loop. Thus
the performance hit, if any, is negligible.)
>
> ... memq is also nice; in case used the list should be done beforehand with
> (let* ...
Given the fact about loop, let* isn?t really applicable.
--
Aaron Ecay
[PATCH 1/2] test/smtp-dummy: add --background option for going background after listen(2)
Hi Tomi.
On Tue, 13 Dec 2011 11:01:22 +0200, Tomi Ollila wrote:
> To avoid the possibility that smtp-dummy doesn't have chance to bind
> its listening socket until something tries to send message to it this
> option makes caller wait until socket is already listening for connections.
>
> In case this --background option is used, the pid of running smtp-dummy
> is printed on stdout.
> ---
>
> Resent after whitespace-cleanup in patch 1/2 (this patch).
>
> test/smtp-dummy.c | 35 ++-
> 1 files changed, 34 insertions(+), 1 deletions(-)
>
> diff --git a/test/smtp-dummy.c b/test/smtp-dummy.c
> index 3801a5e..9126c00 100644
> --- a/test/smtp-dummy.c
> +++ b/test/smtp-dummy.c
> @@ -124,9 +124,21 @@ main (int argc, char *argv[])
> struct hostent *hostinfo;
> socklen_t peer_addr_len;
> int reuse;
> + int bg;
I would rename bg to background, but that is not important.
> +
> + /* XXX Quick implementation -- fix if more functionality is desired. */
> + if (argc >= 2 && strcmp(argv[1], "--background") == 0) {
> + argc--;
> + argv[1] = argv[0];
> + argv++;
> + bg = 1;
> + }
> + else
> + bg = 0;
>
Sorry, this code looks ugly and unnecessary complex to me. I really do
not like messing with argc and argv. Perhaps something like this would
be better:
if (argc != 2 && argc != 3)
usage();
return 1;
if (argc > 2) {
if (argv[1] == background)
bg = 1;
else
usage();
return 1;
}
output = argv[argc - 1];
> if (argc != 2) {
> - fprintf (stderr, "Usage: %s \n", argv[0]);
> + fprintf (stderr, "Usage: %s [--background] \n",
> + argv[0]);
> return 1;
> }
>
> @@ -179,7 +191,27 @@ main (int argc, char *argv[])
> return 1;
> }
>
> + if (bg) {
> + int pid = fork ();
> + if (pid > 0) {
> + printf ("%d\n", pid);
> + return 0;
> + }
> + if (pid < 0) {
> + fprintf (stderr, "Error: fork() failed: %s\n",
> + strerror (errno));
> + close (sock);
> + return 1;
> + }
> + /* Reached if pid == 0. */
> + /* Close stdout so that the one interested in pid value will
> +also get EOF. */
> + close (1);
Please use STDOUT_FILENO instead of 1.
> + /* dup2() will re-reserve fd 1 (opportunistically, in case fd 2
> +is open. If that was not open we don't care fd 1 either.) */
> + dup2 (2, 1);
And STDERR_FILENO and STDOUT_FILENO here. I would prefer to see "stdout"
and "stderr" instead of "1" and "2" in the comments as well.
Regards,
Dmitry
> + }
> +
> peer_addr_len = sizeof (peer_addr);
> peer = accept (sock, (struct sockaddr *) _addr, _addr_len);
> if (peer == -1) {
> --
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
have "notmuch help" call man?
On Fri, 16 Dec 2011 12:01:42 -0400, David Bremner wrote: > What do you think about having "notmuch help foo" invoke "man > notmuch-foo" and create appropriate man pages (or links). I started on this man page splitting. So far I have just been editing the documents, which I attach. The patches are a bit unwieldy, so I'm being a bad person and attaching a tarball (about 20% of the size) for initial review. You can also look at the patches in git://pivot.cs.unb.ca/notmuch branch split-man -- next part -- A non-text attachment was scrubbed... Name: man.tgz Type: application/x-gtar-compressed Size: 9160 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111220/c0449f71/attachment.tgz>
[PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
From a Carl Worth idea: add a function which will select the most recently used notmuch buffer (search, show or hello). If no recent buffer is found, run `notmuch'. It is expected that the user will global bind this command to a key sequence. --- emacs/notmuch.el | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 2e9973e..da61aa9 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1055,6 +1055,23 @@ current search results AND that are tagged with the given tag. (interactive) (notmuch-hello)) +;;;###autoload +(defun notmuch-jump-to-recent-buffer () + Jump to the most recent notmuch buffer (search, show or hello). + +If no recent buffer is found, run `notmuch'. + (interactive) + (let ((last +(loop for buffer in (buffer-list) + if (with-current-buffer buffer + (memq major-mode '(notmuch-show-mode + notmuch-search-mode + notmuch-hello-mode))) + return buffer))) +(if last + (switch-to-buffer last) + (notmuch + (setq mail-user-agent 'notmuch-user-agent) (provide 'notmuch) -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Mon, 22 Nov 2010 11:51:04 +, David Edmondson d...@dme.org wrote:
From a Carl Worth idea: Add `notmuch-jump-to-recent-buffer', which
will select the most recently used notmuch buffer (search, show or
hello). If no recent buffer is found, run `notmuch'.
It is expected that the user will global bind this command to a key
sequence.
---
See comments inline below.
emacs/notmuch.el | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index e8d4d98..67271d1 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -962,6 +962,24 @@ current search results AND that are tagged with the
given tag.
(interactive)
(notmuch-hello))
+;;;###autoload
+(defun notmuch-jump-to-recent-buffer ()
+ Jump to the most recent notmuch buffer (search, show or hello).
+
+If no recent buffer is found, run `notmuch'.
+ (interactive)
+ (let ((last
+ (loop for buffer in (buffer-list)
+if (progn
Are the last few lines above working... if without '(' and no
loop (nor for) function in my emacs (where notmuch loaded).
+ (set-buffer buffer)
I really like Aaron's comment about with-current-buffer...
+ (or (eq major-mode 'notmuch-show-mode)
+ (eq major-mode 'notmuch-search-mode)
+ (eq major-mode 'notmuch-hello-mode)))
... memq is also nice; in case used the list should be done beforehand with
(let* ...
+return buffer)))
+(if last
+ (switch-to-buffer last)
+ (notmuch
+
(setq mail-user-agent 'notmuch-user-agent)
(provide 'notmuch)
--
1.7.2.3
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Mon, 19 Dec 2011 12:58:53 -0500, Aaron Ecay aarone...@gmail.com wrote: (Please excuse the lack of inline comments on the patch – the original patch email is so old that I had deleted it from my archives!) You _deleted_ things? /me faints. progn...set-buffer should be with-current-buffer or...eq...eq... would be cleaner as (memq major-mode '(foo bar baz)) Good comments, thanks. Updated patch sent. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 10:02:11 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
+(loop for buffer in (buffer-list)
+ if (progn
Are the last few lines above working... if without '(' and no
loop (nor for) function in my emacs (where notmuch loaded).
`loop' is an emacs clone of the all singing (It slices, it dices!)
Common Lisp `loop' macro in cl-macs.el.
dme.
--
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/5] Store message modification times in the DB
On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements amdra...@mit.edu wrote: Here are sketches for two sync algorithms with different properties. I haven't proven these to be correct, but I believe they are. In both, R is the remote host and L is the local host. They're both one-way (they only update tags on L), but should be symmetrically stable. Thanks for these. == Two-way merge from host R to host L == Per-host state: - last_mtime: Map from remote hosts to last sync mtime With the proposed changes it seems that the state required on each host would live within the Xapian database (to be extracted with 'dump'). new_mtime = last_mtime[R] For msgid, mtime, tags in messages on host R with mtime = last_mtime[R]: If mtime local mtime of msgid: Set local tags of msgid to tags new_mtime = max(new_mtime, mtime) last_mtime[R] = new_mtime This has the advantage of keeping very little state, but the synchronization is also quite primitive. If two hosts change a message's tags in different ways between synchronizations, the more recent of the two will override the full set of tags on that message. This does not strictly require tombstones, though if you make a tag change and then delete the message before a sync, the tag change will be lost without some record of that state. Does this matter? If the tag on a deleted message is changed, does anyone care? Also, this obviously depends heavily on synchronized clocks. == Three-way merge from host R to host L == Per-host state: - last_mtime: Map from remote hosts to last sync mtime - last_sync: Map from remote hosts to the tag database as of the last sync Any ideas where this state might be kept? new_mtime = last_mtime[R] for msgid, mtime, r_tags in messages on host R with mtime = last_mtime[R]: my_tags = local tags of msgid last_tags = last_sync[R][msgid] for each tag that differs between my_tags and r_tags: if tag is in last_tags: remove tag locally else: add tag locally last_sync[R][msgid] = tags new_mtime = max(new_mtime, mtime) Delete stale messages from last_sync[R] (using tombstones or something) last_mtime[R] = new_mtime This protocol requires significantly more state, but can also reconstruct per-tag changes. Conflict resolution is equivalent to what git would do and is based solely on the current local and remote state and the common ancestor state. This can lead to unintuitive results if a tag on a message has gone through multiple changes on both hosts since the last sync (though, I argue, there are no intuitive results in such situations). Tombstones are only required to garbage collect sync state (and other techniques could be used for that). This also does not depend on time synchronization (though, like any mtime solution, it does depend on mtime monotonicity). The algorithm would work equally well with sequence numbers. I tried coming up with a third algorithm that used mtimes to resolve tagging conflicts, but without per-tag mtimes it degenerated into the first algorithm. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote: + (makunbound 'gnus-summary-buffer) ; Blech. This is working around a bug in gnus. I think the better solution would be for gnus to fix the bug. The following patch against gnus works for me. (I have tried submitting it to the gnus bug list, but have not been able to check if it got through.) I wonder if `boundp' is just a typo for `bufferp'? More on the other comments after thought. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote:
This is working around a bug in gnus.
Arguably this is true, but the real “bug” (conceptual error) is that the
MIME handling libraries and gnus are a little too tightly coupled. Why
should notmuch users have to load gnus (gnus-art.el does (require 'gnus),
which brings in tens of thousands of lines of Elisp)[1], or customize
gnus-* variables to use general-purpose MIME viewing, HTML rendering
facilities?
The best GNUS-side solution would be to make mm-shr GNUS-agnostic, and
probably to introduce shr-{inhibit,blocked}-images as customizable
variables in their own right (which could inherit their values from the
gnus-* versions under the right circumstances).
I hope that the GNUS folks are receptive to this approach, but if they
aren’t I think it’s better for notmuch to not go the way of requiring
that GNUS be loaded to function.
Aaron
[1] I see that (featurep 'gnus) returns t for me, so that horse is
already out of the barn. But it isn’t something we should be
seeking to perpetuate.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 08:01:46 +, David Edmondson d...@dme.org wrote: From a Carl Worth idea: add a function which will select the most recently used notmuch buffer (search, show or hello). If no recent buffer is found, run `notmuch'. It is expected that the user will global bind this command to a key sequence. --- Thanks Aaron David for the explanations. I was finally able to test and byte compile the function separately (as a learning experiment). LGTM. I'd like to know how users are going to use this :) Tomi emacs/notmuch.el | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 2e9973e..da61aa9 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1055,6 +1055,23 @@ current search results AND that are tagged with the given tag. (interactive) (notmuch-hello)) +;;;###autoload +(defun notmuch-jump-to-recent-buffer () + Jump to the most recent notmuch buffer (search, show or hello). + +If no recent buffer is found, run `notmuch'. + (interactive) + (let ((last + (loop for buffer in (buffer-list) +if (with-current-buffer buffer + (memq major-mode '(notmuch-show-mode +notmuch-search-mode +notmuch-hello-mode))) +return buffer))) +(if last + (switch-to-buffer last) + (notmuch + (setq mail-user-agent 'notmuch-user-agent) (provide 'notmuch) -- 1.7.7.3 Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 12:27:02 +0200, Tomi Ollila tomi.oll...@iki.fi wrote: I'd like to know how users are going to use this :) I use it as a way to jump back to whatever I was doing before I was distracted by something in the email I was reading. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4 0/4] emacs: do not call `notmuch-hello-mode' on update
On Sun, 18 Dec 2011 04:21:17 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Changes: v4: * explain why we need to properly delete editable widget fields pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Add `notmuch-jump-to-recent-buffer'.
On Tue, 20 Dec 2011 08:01:46 +, David Edmondson d...@dme.org wrote: From a Carl Worth idea: add a function which will select the most recently used notmuch buffer (search, show or hello). If no recent buffer is found, run `notmuch'. pushed d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 08:35:42 +, David Edmondson d...@dme.org wrote: On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote: + (makunbound 'gnus-summary-buffer) ; Blech. This is working around a bug in gnus. I think the better solution would be for gnus to fix the bug. The following patch against gnus works for me. (I have tried submitting it to the gnus bug list, but have not been able to check if it got through.) I wonder if `boundp' is just a typo for `bufferp'? I originally thought so as well, but bufferp blows up if given an unbound variable and buffer-name blows up if given a string. Cheers, Chris ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray chrismg...@gmail.com wrote: On Tue, 20 Dec 2011 08:35:42 +, David Edmondson d...@dme.org wrote: On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote: + (makunbound 'gnus-summary-buffer) ; Blech. This is working around a bug in gnus. I think the better solution would be for gnus to fix the bug. The following patch against gnus works for me. (I have tried submitting it to the gnus bug list, but have not been able to check if it got through.) I wonder if `boundp' is just a typo for `bufferp'? I originally thought so as well, but bufferp blows up if given an unbound variable and buffer-name blows up if given a string. When would `gnus-summary-buffer' ever be unbound? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/5] Store message modification times in the DB
Quoth David Edmondson on Dec 20 at 8:32 am: == Two-way merge from host R to host L == Per-host state: - last_mtime: Map from remote hosts to last sync mtime With the proposed changes it seems that the state required on each host would live within the Xapian database (to be extracted with 'dump'). It certainly could. I haven't thought about how any of this would integrate with dump, or if it necessarily should. A related question is how bootstrap should work. For example, if you add another host, what's the best way to bring it up to speed without, say, overwriting your tags everywhere with your initial tags? In general, when a new message arrives, how do you get the hosts to agree on its tags and what happens if one host tags it before another host sees it? new_mtime = last_mtime[R] For msgid, mtime, tags in messages on host R with mtime = last_mtime[R]: If mtime local mtime of msgid: Set local tags of msgid to tags new_mtime = max(new_mtime, mtime) last_mtime[R] = new_mtime This has the advantage of keeping very little state, but the synchronization is also quite primitive. If two hosts change a message's tags in different ways between synchronizations, the more recent of the two will override the full set of tags on that message. This does not strictly require tombstones, though if you make a tag change and then delete the message before a sync, the tag change will be lost without some record of that state. Does this matter? If the tag on a deleted message is changed, does anyone care? That depends on what sort of synchronization model you're expecting. If you're expecting git-style synchronization where all that matters is the state and not the order things happened in, then this is exactly what you'd expect. If you're expecting something more nuanced that knows about the order you did things in across hosts between synchronizations (which I think can only lead to more unintuitive corner-cases, but some people seem to expect), then this could be surprising. Also, this obviously depends heavily on synchronized clocks. == Three-way merge from host R to host L == Per-host state: - last_mtime: Map from remote hosts to last sync mtime - last_sync: Map from remote hosts to the tag database as of the last sync Any ideas where this state might be kept? It could also be stored in Xapian (in user keys or as additional message metadata). That would certainly be simplest and would avoid hairy atomicity issues. OTOH, it's not the end of the world if last_sync doesn't get updated atomically, especially if we can at least guarantee last_sync is fully updated and on disk before we update last_mtime. new_mtime = last_mtime[R] for msgid, mtime, r_tags in messages on host R with mtime = last_mtime[R]: my_tags = local tags of msgid last_tags = last_sync[R][msgid] for each tag that differs between my_tags and r_tags: if tag is in last_tags: remove tag locally else: add tag locally last_sync[R][msgid] = tags new_mtime = max(new_mtime, mtime) Delete stale messages from last_sync[R] (using tombstones or something) last_mtime[R] = new_mtime This protocol requires significantly more state, but can also reconstruct per-tag changes. Conflict resolution is equivalent to what git would do and is based solely on the current local and remote state and the common ancestor state. This can lead to unintuitive results if a tag on a message has gone through multiple changes on both hosts since the last sync (though, I argue, there are no intuitive results in such situations). Tombstones are only required to garbage collect sync state (and other techniques could be used for that). This also does not depend on time synchronization (though, like any mtime solution, it does depend on mtime monotonicity). The algorithm would work equally well with sequence numbers. I tried coming up with a third algorithm that used mtimes to resolve tagging conflicts, but without per-tag mtimes it degenerated into the first algorithm. dme. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch: Quiet buildbot warnings.
Cast away the result of various *write functions. Provide a default
value for some variables to avoid use before set warnings.
---
The buildbot complains about these, though my own system (Debian
testing on amd64) does not.
lib/database.cc |2 +-
notmuch-new.c |2 +-
notmuch-show.c |2 +-
notmuch-tag.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 98f101e..f1a9dc2 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1447,7 +1447,7 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
keys = g_hash_table_get_keys (parents);
for (l = keys; l; l = l-next) {
char *parent_message_id;
- const char *parent_thread_id;
+ const char *parent_thread_id = NULL;
parent_message_id = (char *) l-data;
diff --git a/notmuch-new.c b/notmuch-new.c
index bfb4600..3512de7 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -67,7 +67,7 @@ handle_sigint (unused (int sig))
{
static char msg[] = Stopping... \n;
-write(2, msg, sizeof(msg)-1);
+(void) write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
diff --git a/notmuch-show.c b/notmuch-show.c
index 8da3295..19fb49f 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -866,7 +866,7 @@ do_show_single (void *ctx,
while (!feof (file)) {
size = fread (buf, 1, sizeof (buf), file);
- fwrite (buf, size, 1, stdout);
+ (void) fwrite (buf, size, 1, stdout);
}
fclose (file);
diff --git a/notmuch-tag.c b/notmuch-tag.c
index 537d5a4..292c5da 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,7 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = Stopping... \n;
-write(2, msg, sizeof(msg)-1);
+(void) write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: More ideas about logging.
On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner brem...@debian.org wrote: The more worrying part is disk usage; the tag tree for 200k messages uses 400k inodes, and 836M of apparent disk usage (according to du) the same tags in sup format take 11M. Maybe this could be usefull if combined with some scheme to only dump tags not covered by maildir (for those using maildir flag synching already) Well, it would seem natural to re-use the nmbug logic here, and just use a bare git repo for this. One would need a way to sync and merge the tag-tree automatically anyway. I admit I haven't tried nmbug yet, but it seems that nmbug, switched from sync just notmuch:: to syncing everything but notmuch:: would be a sensible way to sync tags? Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [alot] Introducing myself, asking various questions
On Sun, 18 Dec 2011 19:59:28 +0100, Krzysztof Ilowiecki k...@ilowiecki.com wrote: I understand synchronisation across machines and with IMAP is something of an issue so far. How bad would it be to use git for that - and for 'undo'? It would appear some people use git+maildir even instead of IMAP, but I guess the notmuch's database may be completely unsuitable... I use git+maildir to sync my mails, and use notmuch dump+restore to sync my tags. But currently, the tag syncing I do manually, mostly when I go out-of-town with my laptop, since it still seems to expensive to do it regularly (1 day). In particular, I don't sync the notmuch db itself, at all. Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/5] Store message modification times in the DB
On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements amdra...@mit.edu wrote: This protocol requires significantly more state, but can also reconstruct per-tag changes. Conflict resolution is equivalent to what git would do and is based solely on the current local and remote state and the common ancestor state. This seems like exactly what one would get if one stored the tag state in git, which seems like a reasonable thing to do anyway. This can lead to unintuitive results if a tag on a message has gone through multiple changes on both hosts since the last sync (though, I argue, there are no intuitive results in such situations). I certainly agree that there isn't a universally good resolution to this. I suspect that the same person, making the same tag changes with the same mtimes, will want different resolutions at different times. This is because there is no good way to record the intent of the changes. Tombstones are only required to garbage collect sync state (and other techniques could be used for that). I wonder how many people using notmuch actually delete mail? I know I don't bother to, anymore. One use case that was mentioned, is having a limited amount of mail on a portable device, and syncing tags on those message present. Using git to record the tag state, one would just need to record the state before deleting files, to avoid the need for tombstones in the notmuch db. Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 14:33:01 +, David Edmondson d...@dme.org wrote: On Tue, 20 Dec 2011 07:27:24 -0700, Chris Gray chrismg...@gmail.com wrote: On Tue, 20 Dec 2011 08:35:42 +, David Edmondson d...@dme.org wrote: On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote: + (makunbound 'gnus-summary-buffer) ; Blech. This is working around a bug in gnus. I think the better solution would be for gnus to fix the bug. The following patch against gnus works for me. (I have tried submitting it to the gnus bug list, but have not been able to check if it got through.) I wonder if `boundp' is just a typo for `bufferp'? I originally thought so as well, but bufferp blows up if given an unbound variable and buffer-name blows up if given a string. When would `gnus-summary-buffer' ever be unbound? In the optimal situation where we were able to use mm-decode without requiring gnus.el, then gnus-summary-buffer would be unbound. Cheers, Chris ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
On Tue, 20 Dec 2011 03:40:44 -0500, Aaron Ecay aarone...@gmail.com wrote: On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray chrismg...@gmail.com wrote: This is working around a bug in gnus. Arguably this is true, but the real “bug” (conceptual error) is that the MIME handling libraries and gnus are a little too tightly coupled. Why should notmuch users have to load gnus (gnus-art.el does (require 'gnus), which brings in tens of thousands of lines of Elisp)[1], or customize gnus-* variables to use general-purpose MIME viewing, HTML rendering facilities? I agree with this 100%. However, we should still try to use emacs coding best-practices, which means not defining variables that are defined in other packages. Unfortunately, getting the gnus folks to fix their library might take a while, so it might be okay to relax those best-practices while we wait, but we should be aware of the fact that that's what we're doing. Cheers, Chris ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/2] emacs: trivial defcustom fixes
Hi all, v2 of a couple of defcustom fixes. Now with a default value for Custom filter in patch 1/2 as suggested by Dmitry. No other changes. BR, Jani. Jani Nikula (2): emacs: Fix notmuch-hello-tag-list-make-query defcustom emacs: Fix notmuch-mua-user-agent defcustom emacs/notmuch-hello.el |5 +++-- emacs/notmuch-mua.el | 10 ++ 2 files changed, 9 insertions(+), 6 deletions(-) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
It was not possible to define custom filters or filter functions because the types were const. Remove const to allow editing. Signed-off-by: Jani Nikula j...@nikula.org --- emacs/notmuch-hello.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 81b2605..7dd0f85 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -86,8 +86,9 @@ Finally this can be a function that will be called for each tag and should return a filter for that tag, or nil to hide the tag. :type '(choice (const :tag All messages nil) (const :tag Unread messages tag:unread) -(const :tag Custom filter string) -(const :tag Custom filter function function)) +(string :tag Custom filter +:value tag:unread) +(function :tag Custom filter function)) :group 'notmuch) (defcustom notmuch-hello-hide-tags nil -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 2/2] emacs: Fix notmuch-mua-user-agent defcustom
The :options keyword is not meaningful for function type. Also, it was not possible to enter nil value, contrary to the notmuch-mua-user-agent defcustom documentation. Specify the alternatives using choice type, taking nil into account. Signed-off-by: Jani Nikula j...@nikula.org --- emacs/notmuch-mua.el | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index b525762..7114e48 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -35,10 +35,12 @@ Function used to generate a `User-Agent:' string. If this is `nil' then no `User-Agent:' will be generated. :group 'notmuch - :type 'function - :options '(notmuch-mua-user-agent-full -notmuch-mua-user-agent-notmuch -notmuch-mua-user-agent-emacs)) + :type '(choice (const :tag No user agent string nil) +(const :tag Full notmuch-mua-user-agent-full) +(const :tag Notmuch notmuch-mua-user-agent-notmuch) +(const :tag Emacs notmuch-mua-user-agent-emacs) +(function :tag Custom user agent function + :value notmuch-mua-user-agent-full))) (defcustom notmuch-mua-hidden-headers '(^User-Agent:) Headers that are added to the `message-mode' hidden headers -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: create patch filename from subject for inline patch fake parts
Shameless promotion of own patches... I suppose not many use the notmuch-wash-convert-inline-patch-to-part option, but with this patch I've actually started to like it better. An actual patch name from subject instead of inline patch. As I said, the lisp is less than perfect here, but this is still better than what's existing. Any comments? BR, Jani. On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula j...@nikula.org wrote: Use the mail subject line for creating a descriptive filename for the wash generated inline patch fake parts. The names are similar to the ones created by 'git format-patch', just without the leading numbers. Signed-off-by: Jani Nikula j...@nikula.org --- I know notmuch-subject-to-patch-filename is totally un-lispy. Suggestions welcome on how to make it lispy and keep it somewhat readable. If we later want to have a '' counterpart to '|' to save messages to files rather than pipe, then this could be generalized and re-used for creating the suggested filename for that. I don't even use the notmuch-wash-convert-inline-patch-to-part option that much, but having it suggest inline patch as filename is just ugly... --- emacs/notmuch-wash.el | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 1f420b2..755d64a 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -290,6 +290,17 @@ When doing so, maintaining citation leaders in the wrapped text. (defvar diff-file-header-re) ; From `diff-mode.el'. +(defun notmuch-subject-to-patch-filename (str) + Convert a typical patch mail subject line into a suitable filename. + (let ((s str)) +(setq s (replace-regexp-in-string ^ *\\(\\[[^]]*\\]\\)? * s)) +(setq s (replace-regexp-in-string [. ]*$ s)) +(setq s (replace-regexp-in-string [^A-Za-z0-9._-]+ - s)) +(setq s (replace-regexp-in-string \\.+ . s)) +(when ( (length s) 52) + (setq s (substring s 0 52))) +(concat s .patch))) + (defun notmuch-wash-convert-inline-patch-to-part (msg depth) Convert an inline patch into a fake 'text/x-diff' attachment. @@ -316,7 +327,10 @@ for error. (setq part (plist-put part :content-type text/x-diff)) (setq part (plist-put part :content (buffer-string))) (setq part (plist-put part :id -1)) - (setq part (plist-put part :filename inline patch)) + (setq part (plist-put part :filename + (notmuch-subject-to-patch-filename +(plist-get + (plist-get msg :headers) :Subject (delete-region (point-min) (point-max)) (notmuch-show-insert-bodypart nil part depth)) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: create patch filename from subject for inline patch fake parts
Hi Jani. On Tue, 20 Dec 2011 22:05:31 +0200, Jani Nikula j...@nikula.org wrote: Shameless promotion of own patches... I suppose not many use the notmuch-wash-convert-inline-patch-to-part option, but with this patch I've actually started to like it better. An actual patch name from subject instead of inline patch. As I said, the lisp is less than perfect here, but this is still better than what's existing. Any comments? I do not use the option but the patch sounds useful to me. I would try to review it soon. I think a simple test would be useful here BTW. Regards, Dmitry BR, Jani. On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula j...@nikula.org wrote: Use the mail subject line for creating a descriptive filename for the wash generated inline patch fake parts. The names are similar to the ones created by 'git format-patch', just without the leading numbers. Signed-off-by: Jani Nikula j...@nikula.org --- I know notmuch-subject-to-patch-filename is totally un-lispy. Suggestions welcome on how to make it lispy and keep it somewhat readable. If we later want to have a '' counterpart to '|' to save messages to files rather than pipe, then this could be generalized and re-used for creating the suggested filename for that. I don't even use the notmuch-wash-convert-inline-patch-to-part option that much, but having it suggest inline patch as filename is just ugly... --- emacs/notmuch-wash.el | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 1f420b2..755d64a 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -290,6 +290,17 @@ When doing so, maintaining citation leaders in the wrapped text. (defvar diff-file-header-re) ; From `diff-mode.el'. +(defun notmuch-subject-to-patch-filename (str) + Convert a typical patch mail subject line into a suitable filename. + (let ((s str)) +(setq s (replace-regexp-in-string ^ *\\(\\[[^]]*\\]\\)? * s)) +(setq s (replace-regexp-in-string [. ]*$ s)) +(setq s (replace-regexp-in-string [^A-Za-z0-9._-]+ - s)) +(setq s (replace-regexp-in-string \\.+ . s)) +(when ( (length s) 52) + (setq s (substring s 0 52))) +(concat s .patch))) + (defun notmuch-wash-convert-inline-patch-to-part (msg depth) Convert an inline patch into a fake 'text/x-diff' attachment. @@ -316,7 +327,10 @@ for error. (setq part (plist-put part :content-type text/x-diff)) (setq part (plist-put part :content (buffer-string))) (setq part (plist-put part :id -1)) - (setq part (plist-put part :filename inline patch)) + (setq part (plist-put part :filename + (notmuch-subject-to-patch-filename + (plist-get + (plist-get msg :headers) :Subject (delete-region (point-min) (point-max)) (notmuch-show-insert-bodypart nil part depth)) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: More ideas about logging.
On Sun, 18 Dec 2011 13:22:20 -0700, Tom Prince tom.pri...@ualberta.net wrote: On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner brem...@debian.org wrote: The more worrying part is disk usage; the tag tree for 200k messages uses 400k inodes, and 836M of apparent disk usage (according to du) the same tags in sup format take 11M. Maybe this could be usefull if combined with some scheme to only dump tags not covered by maildir (for those using maildir flag synching already) Well, it would seem natural to re-use the nmbug logic here, and just use a bare git repo for this. One would need a way to sync and merge the tag-tree automatically anyway. I admit I haven't tried nmbug yet, but it seems that nmbug, switched from sync just notmuch:: to syncing everything but notmuch:: would be a sensible way to sync tags? I was mainly interested in if some guarantee of atomicity could be given in a simple way. The git update-index approach doesn't really make those kind of guaranteees.. Probably this is tolerable for a human initiated dump process; not so much for other uses. Furthermore much of the motivation for both mtimes and logging is to make incremental dumping possible in order to avoid the time to do of a full dump. This is experiment was also to see how feasible it was to insert some mkdir+creat in the notmuch-tag critical path. Since a few people have mentioned this, I should confess that there are (at least) 2 performance bugs lurking in nmbug that make it probably not yet suitable for large scale tag syncing. 1) I did not get the merging working with only the index, so nmbug currently makes a temporary checkout to do the merge. 2) transfering tags from the git repo to xapian is currently quite slow because it does one call to git tag for each tag, rather than constructing an input for notmuch restore. I _think_ both of these are fixable in principle. Maybe somebody with better git internals knowledge than I would like to take a look at (1). (2) is just a SimpleMatterOfProgramming (TM). Patches, as they say, are welcome ;). d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: create patch filename from subject for inline patch fake parts
Seems like a definite improvement, but perhaps a let* instead of all of the setq's? Quoth Jani Nikula on Dec 20 at 10:05 pm: Shameless promotion of own patches... I suppose not many use the notmuch-wash-convert-inline-patch-to-part option, but with this patch I've actually started to like it better. An actual patch name from subject instead of inline patch. As I said, the lisp is less than perfect here, but this is still better than what's existing. Any comments? BR, Jani. On Sat, 19 Nov 2011 01:02:48 +0200, Jani Nikula j...@nikula.org wrote: Use the mail subject line for creating a descriptive filename for the wash generated inline patch fake parts. The names are similar to the ones created by 'git format-patch', just without the leading numbers. Signed-off-by: Jani Nikula j...@nikula.org --- I know notmuch-subject-to-patch-filename is totally un-lispy. Suggestions welcome on how to make it lispy and keep it somewhat readable. If we later want to have a '' counterpart to '|' to save messages to files rather than pipe, then this could be generalized and re-used for creating the suggested filename for that. I don't even use the notmuch-wash-convert-inline-patch-to-part option that much, but having it suggest inline patch as filename is just ugly... --- emacs/notmuch-wash.el | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 1f420b2..755d64a 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -290,6 +290,17 @@ When doing so, maintaining citation leaders in the wrapped text. (defvar diff-file-header-re) ; From `diff-mode.el'. +(defun notmuch-subject-to-patch-filename (str) + Convert a typical patch mail subject line into a suitable filename. + (let ((s str)) +(setq s (replace-regexp-in-string ^ *\\(\\[[^]]*\\]\\)? * s)) +(setq s (replace-regexp-in-string [. ]*$ s)) +(setq s (replace-regexp-in-string [^A-Za-z0-9._-]+ - s)) +(setq s (replace-regexp-in-string \\.+ . s)) +(when ( (length s) 52) + (setq s (substring s 0 52))) +(concat s .patch))) + (defun notmuch-wash-convert-inline-patch-to-part (msg depth) Convert an inline patch into a fake 'text/x-diff' attachment. @@ -316,7 +327,10 @@ for error. (setq part (plist-put part :content-type text/x-diff)) (setq part (plist-put part :content (buffer-string))) (setq part (plist-put part :id -1)) - (setq part (plist-put part :filename inline patch)) + (setq part (plist-put part :filename + (notmuch-subject-to-patch-filename + (plist-get + (plist-get msg :headers) :Subject (delete-region (point-min) (point-max)) (notmuch-show-insert-bodypart nil part depth)) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: don't ask users to do 'sudo make install'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/11 15:34, David Bremner wrote: On Wed, 07 Dec 2011 15:05:02 +0100, Rainer M Krug r.m.k...@gmail.com wrote: Because of these problems, I use checkinstall to create a deb file ( I am using Ubuntu) which I can then un-install again if I want to, or update, or anything the package manager can do. Note that in recent versions of notmuch, make debian-snapshot is probably a better option than checkinstall, since it uses the official debian packaging that ships with notmuch. Interesting. I assume, I have to do ./configure make make debian-snapshot but this resulted in the following error: dpkg-buildpackage: warning: (Use -d flag to override.) debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed make: *** [debian-snapshot] Error 29 I also tried it with the sudo afterwards, but I got the same error, so I used checkinstall again and it worked without problems: sudo checkinstall --fstrans=yes But why did I get this error? Rainer I don't know how practical/useful it is to support something similar for other distros / OSes, but we could certainly consider it. d - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ffg0ACgkQoYgNqgF2egqcVACfR3C2VM+RmOyxqGcG1sqTfMvJ q5gAnAvqoeYIM5OMHmL1eZAeLR6bq5KZ =jVSe -END PGP SIGNATURE- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
S/MIME support in notmuch
I'd like to report some success on getting S/MIME signature verification working using notmuch and the recently-released GMime 2.6. I specifically tested with notmuch-0.10.2 and gmime-2.6.1. The following changes were required: 1) notmuch: Apply patch from Redhat packaging to handle API changes from gmime-2.4 to gmime-2.6 (see compile error of current git on F15 thread from 25 November on the list) 2) notmuch: Create a S/MIME context instead of the GPG context in notmuch-show.c. g_mime_gpg_context_new() becomes g_mime_pkcs7_context_new(), and similarly for g_mime_gpg_context_set_always_trust(). 3) gmime: The pkcs7 context only works with signatures of application/pkcs7-signature. Per RFC2311 section C, both application/pkcs7-signature and application/x-pkcs7-signature should be treated identically. I temporarily disabled this check in gmime/gmime-multipart-signed.c and then gmime accepted the signatures. Next, I was always seeing signature verification errors with completely unhelpful error messages. These turned out to be because the 'gpg-agent' program was not running. Once I started the agent, I got prompts on trusting root certs and was then able to see known-valid certificates verified in the emacs UI. NB: I started gpg-agent with the --allow-mark-trusted option so that it would graphically prompt me for which root certificates to trust. See http://lists.gnupg.org/pipermail/gnupg-users/2004-September/023247.html for more detail on some of the general setup choices for the GPG S/MIME stack. The most useful command for debugging the underlying S/MIME configuration was gpgsm --list-chain --with-validation. I don't have submittable patches for #2/#3 yet, but I wanted to share what I found about the scope of what actually needs to be done, which is fairly small. (The biggest blocker is probably that Debian other distros haven't packaged gmime-2.6.) Dan ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: don't ask users to do 'sudo make install'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/11 20:52, David Bremner wrote: On Wed, 07 Dec 2011 15:54:05 +0100, Rainer M Krug r.m.k...@gmail.com wrote: Interesting. I assume, I have to do ./configure make make debian-snapshot Just make debian-snapshot should work if you have the packages dpkg-dev and fakeroot installed. dpkg-buildpackage: warning: (Use -d flag to override.) debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed make: *** [debian-snapshot] Error 29 Is this all of your output? It's a pretty generic error saying dpkg-buildpackage didn't work. If there is no other output, then I guess you might be missing dpkg-buildpackage. Nope - installed. I looked more closely, and dtach was missing. Installed it, and it is working now. Thanks a lot, Rainer d - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7giSgACgkQoYgNqgF2egqHDgCfWtFJRxZ4MwwAdsZUd90JrQCq KegAn1BHFeemTNl2g3yMbqtqWbxwHdgU =oBq4 -END PGP SIGNATURE- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Question : Tag mail according to it directory path ?
Hi there ! I'm looking for using notmuch as my regular MUA, but I have a trouble so far. I have a 4000+ mail collection already sorted in folders. The point is I would like to tag those mails through the notmuch database according to those folders. (i.g. the mails in the friend/foo directory will be tagged as friend and foo) Is there any way to do this easily or should I make a quick'n dirty script to do the job ? (i.e. cat each mail of a folder, sed to get subject/receivers ect and do a notmuch search and tag with those arguments) Regards -- G.bleu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Question : Tag mail according to it directory path ?
On Mon, 12 Dec 2011 21:59:09 +0100, emmanuel.lebl...@gmail.com wrote: I have a 4000+ mail collection already sorted in folders. The point is I would like to tag those mails through the notmuch database according to those folders. (i.g. the mails in the friend/foo directory will be tagged as friend and foo) Hi, Emanuel. There is already the ability to search for messages by path with the folder: search prefix. From notmuch help search-terms: The folder: prefix can be used to search for email message files that are contained within particular directories within the mail store. Only the directory components below the top-level mail database path are available to be searched. You can then easily apply arbitrary tags with something like: notmuch tag +foo -- folder:foo hth. jamie. pgp3ljjUtJXiY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: add notmuch-hello-refresh-hook
This hook is called every time a notmuch-hello buffer is updated. --- Hi Dmitry, I like the idea of having a -mode-hook and a -refresh-hook :) Thanks for your suggestions! Regards, Thomas emacs/notmuch-hello.el |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 115f80a..9fa3137 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -143,6 +143,11 @@ Typically \,\ in the US and UK and \.\ or \ \ in Europe. :group 'notmuch :type 'hook) +(defcustom notmuch-hello-refresh-hook nil + Functions called after updating a `notmuch-hello' buffer. + :type 'hook + :group notmuch) + (defvar notmuch-hello-url http://notmuchmail.org; The `notmuch' web site.) @@ -590,7 +595,9 @@ Complete list of currently available key bindings: (widget-forward 1))) (unless (widget-at) - (notmuch-hello-goto-search) + (notmuch-hello-goto-search + + (run-hooks 'notmuch-hello-refresh-hook)) (defun notmuch-folder () Deprecated function for invoking notmuch---calling `notmuch' is preferred now. -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 3/4] emacs: rename notmuch-decimal-separator to notmuch-thousands-separator
On Fri, 16 Dec 2011 16:34:03 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Fri, 16 Dec 2011 08:29:00 -0400, David Bremner da...@tethera.net wrote: On Fri, 16 Dec 2011 04:59:22 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: What do perople think about making the thousands separator a space by default? Is that really good for a majority of users? I had never heard of it until now. I know this is hardly scientific, but still... Well, to me 1 000 000 000 looks better than 1,000,000,000. But I do not know about the others. That is why I was asking :) That's a complex topic unfortunately. I prefer 1 000 000 too, but many would prefer 1,000,000, others would prefer 1'000'000, and in India many would even prefer 1,00, (https://en.wikipedia.org/wiki/Thousands_separator#Examples_of_use). The cleanest solution would be to use something that cares about the LC_NUMERIC environment variable. sprintf() can do such things, but I'm not aware of any possibility to do that in elisp. -- Thomas/Schnouki pgpyIvPp7KX9G.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/5] lib: Add a MTIME value to every mail document
On Wed, 14 Dec 2011 14:54:10 -0700, Mark Anderson markr.ander...@amd.com wrote: On Tue, 13 Dec 2011 11:11:42 -0600, Thomas Jost schno...@schnouki.net wrote: This is a time_t value, similar to the message date (TIMESTAMP). It is first set when the message is added to the database, and is then updated every time a tag is added or removed. It can thus be used for doing incremental dumps of the database or for synchronizing it between several computers. This value can be read freely (with notmuch_message_get_mtime()) but for now it can't be set to an arbitrary value: it can only be set to now when updated. There's no specific reason for this except that I don't really see a real use case for setting it to an arbitrary value. I think it would be easier to write some testcases if the last modified time could be touched directly. Perhaps they aren't in the set of must have, but it's what comes to mind. Well since I posted this, I found other good reasons to have a set_mtime function. I'll post an updated series lated which will include it -- and possibly some tests too :) Thanks, -- Thomas/Schnouki pgpibTonQiSUF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/5] lib: Add a MTIME value to every mail document
On Wed, 14 Dec 2011 19:45:07 -0500, Austin Clements amdra...@mit.edu wrote:
A few minor comments below.
At a higher level, I'm curious what the tag synchronization protocol
you're building on top of this is. I can't think of one that doesn't
have race conditions, but maybe I'm not thinking about it right.
The approach I've used is quite different from what you described in
id:20111219194821.ga10...@mit.edu. I don't directly sync host A to
host B but I use a server in the middle. (A is my laptop -- not always
on, B is my work PC -- turned off when I'm out of office, so a direct
sync would be harder to do).
My nm-sync script is written in Python 2 (2.7, may work with 2.6) and is
present on both my PCs and on my server. It can operate in two modes :
client (when run from one of my PCs) or server (called *from the client*
through ssh, running on my server).
When running in server mode, the script manipulates a small DB stored as
a Python dictionary (and stored on disk with the pickle module). It does
not even need notmuch to be installed on the server. Here is what this
DB looks like:
{
lastseen: {
pc_A: 1324428029,
pc_B: 1323952028
},
messages: {
msgid_001: (mtime, tag1, tag2, ..., tagN),
msgid_002: (mtime, tag1, tag2, ..., tagM),
...
}
}
So when running the client, here is what happens:
1. client starts a subprocess: ssh myserver ~/nm-sync server
2. client and server check that their sha1sum match (to avoid version
mismatch)
3. client identifies itself with its hostname (pc_A in the example
above), server replies with its lastseen value and updates its in
the DB
4. server sends to client messages with mtime lastseen (msgid + mtime
+ tags), client updates the notmuch DB with these values
5. client queries the notmuch DB for messages with mtime lastseen and
sends them (msgid + mtime + tags) to the server, which stores them in
the DB
6. cleanup: server removes messages with mtime min(lastseen) from its
DB
So basically this approach assumes that all clocks are synchronized
(everyone uses ntp, right?...) and does not even try to detect
conflicts: if a message has been modified both locally and remotely,
then the local version will be overwritten by the remote one, period. It
should also work with more than 2 hosts (but not tested yet). No sync
data is kept in the notmuch DB.
Right now all of this fits in about 250 lines of Python (could be made
shorter) and works quite well for me. I'll put it online after doing
some cleanup.
Quoth Thomas Jost on Dec 13 at 6:11 pm:
This is a time_t value, similar to the message date (TIMESTAMP). It is
first set
when the message is added to the database, and is then updated every time a
tag
is added or removed. It can thus be used for doing incremental dumps of the
database or for synchronizing it between several computers.
This value can be read freely (with notmuch_message_get_mtime()) but for
now it
can't be set to an arbitrary value: it can only be set to now when
updated.
There's no specific reason for this except that I don't really see a real
use
case for setting it to an arbitrary value.
---
lib/database.cc |7 ++-
lib/message.cc| 32
lib/notmuch-private.h |6 +-
lib/notmuch.h |4
4 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 2025189..6dc6f73 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -81,7 +81,7 @@ typedef struct {
* STRING is the name of a file within that
* directory for this mail message.
*
- *A mail document also has four values:
+ *A mail document also has five values:
*
* TIMESTAMP: The time_t value corresponding to the message's
* Date header.
@@ -92,6 +92,9 @@ typedef struct {
*
* SUBJECT:The value of the Subject header
*
+ * MTIME: The time_t value corresponding to the last time
+ * a tag was added or removed on the message.
+ *
* In addition, terms from the content of the message are added with
* from, to, attachment, and subject prefixes for use by the
* user in searching. Similarly, terms from the path of the mail
@@ -1735,6 +1738,8 @@ notmuch_database_add_message (notmuch_database_t
*notmuch,
date = notmuch_message_file_get_header (message_file, date);
_notmuch_message_set_header_values (message, date, from, subject);
+_notmuch_message_update_mtime (message);
Indentation.
Fixed, thanks.
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/message.cc b/lib/message.cc
index 0075425..0c98589 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -830,6 +830,34 @@
[PATCH] emacs: add notmuch-hello-refresh-hook
This hook is called every time a notmuch-hello buffer is updated. --- Oops, the previous patch had a typo which prevented it to work (:group notmuch instead of :group 'notmuch). Sorry about that. emacs/notmuch-hello.el |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 115f80a..a2b1c4c 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -143,6 +143,11 @@ Typically \,\ in the US and UK and \.\ or \ \ in Europe. :group 'notmuch :type 'hook) +(defcustom notmuch-hello-refresh-hook nil + Functions called after updating a `notmuch-hello' buffer. + :type 'hook + :group 'notmuch) + (defvar notmuch-hello-url http://notmuchmail.org; The `notmuch' web site.) @@ -590,7 +595,9 @@ Complete list of currently available key bindings: (widget-forward 1))) (unless (widget-at) - (notmuch-hello-goto-search) + (notmuch-hello-goto-search + + (run-hooks 'notmuch-hello-refresh-hook)) (defun notmuch-folder () Deprecated function for invoking notmuch---calling `notmuch' is preferred now. -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add notmuch-hello-refresh-hook
Hi Thomas. Looks good to me. We should also add tests for this, similar to those for `notmuch-hello-mode-hook'. Thomas, do you think you can work on it? Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 3/4] emacs: rename notmuch-decimal-separator to notmuch-thousands-separator
Hi Thomas. On Wed, 21 Dec 2011 01:30:48 +0100, Thomas Jost schno...@schnouki.net wrote: On Fri, 16 Dec 2011 16:34:03 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Fri, 16 Dec 2011 08:29:00 -0400, David Bremner da...@tethera.net wrote: On Fri, 16 Dec 2011 04:59:22 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: What do perople think about making the thousands separator a space by default? Is that really good for a majority of users? I had never heard of it until now. I know this is hardly scientific, but still... Well, to me 1 000 000 000 looks better than 1,000,000,000. But I do not know about the others. That is why I was asking :) That's a complex topic unfortunately. I prefer 1 000 000 too, but many would prefer 1,000,000, others would prefer 1'000'000, and in India many would even prefer 1,00, (https://en.wikipedia.org/wiki/Thousands_separator#Examples_of_use). The cleanest solution would be to use something that cares about the LC_NUMERIC environment variable. sprintf() can do such things, but I'm not aware of any possibility to do that in elisp. We discussed this on IRC. And, surprisingly, everyone agreed on changing the default to a space in a separate patch. But my other comment for this patch is still relevant: please rename `notmuch-thousands-separator' to `notmuch-hello-thousands-separator'. If you decide to make another patch that changes the default to a space, please add this link [1] to the preamble and a citation: Therefore the space is recommended in the SI/ISO 31-0 standard, and the International Bureau of Weights and Measures states that for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three. Regards, Dmitry [1] http://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping -- Thomas/Schnouki ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
