Re: [notmuch] Notmuch's search view sucks
--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen: [...] TextCat is in Perl. I don't know if there's a C or C++ implementation but it isn't a huge piece of code - finding a good technique was the clever part of it. The same algorithm is implemented in C here: http://www.mnogosearch.org/guesser/ Licensed under the GPL and includes presets for ~50 languages. A potential drawback is that it doesn't handle raw HTML very well, according to the documentation. Aaron ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch.el: colorize lines in notmuch-search based on thread tags.
--- 2010ko Otsailak 7an, Aneesh Kumar K. V-ek idatzi zuen: Doesn't 92c4dcc641e9dfb5f65026ebae5cedc8eb1d9e21 help you achive something similar ? That commit allows colors to be applied to the tag name only, whereas this patch applies the color to the whole line. Which method(s) notmuch should support is debatable, of course. Mutt does whole-line coloring, FWIW. I should also point out that tag-based coloring is problematic in the current emacs interface, wherein long subjects can push the tags off the right side of the window. That is arguably a bug, but until it is fixed the utility of tag-only coloring is limited. Aaron ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Build problems on OS X
In the process of updating to the latest sources, I've discovered that notmuch no longer builds on OS X. As a reply to this email, I'll be sending 4 patches. The first two are bugfixes; the third adds the infrastructure to the Makefiles to build a shared library on OS X, since the Mach-O conventions are somewhat different than the Linux ones. Modulo makefile style quibbles, this patch should be correct. The fourth patch I am not sure of. Even after adding the proper command line flags to build the shared binary on OS X, I get symbol not found errors for Glib/Gmime symbols. The shared binary links against the shared lib, which in turn links against Glib and Gmime, but it appears that at least on OS X the linker won't follow these second-order links, and the notmuch shared binary must be linked against Glib/Gmime directly. This patch fixes the build for me, but it may not be correct on Linux/other Unices. I can resubmit this patch to add the extra linker flags only when building for OS X. If anyone knows how to get the OS X linker to behave like the Linux one in this regard, that will likely be a better solution. Aaron ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] Use C++ compiler to link notmuch binaries
Since the binaries contain C++ code, it is necessary to use the C++ linker, or errors result on some platforms (OS X). Signed-off-by: Aaron Ecay aarone...@gmail.com --- Makefile.local |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.local b/Makefile.local index 71525e2..9e753cd 100644 --- a/Makefile.local +++ b/Makefile.local @@ -216,10 +216,10 @@ notmuch_client_srcs = \ notmuch_client_modules = $(notmuch_client_srcs:.c=.o) notmuch: $(notmuch_client_modules) lib/libnotmuch.a - $(call quiet,CC $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@ + $(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@ notmuch-shared: $(notmuch_client_modules) lib/libnotmuch.so - $(call quiet,CC $(CFLAGS)) $(notmuch_client_modules) $(FINAL_NOTMUCH_LDFLAGS) -o $@ + $(call quiet,CXX $(CFLAGS)) $(notmuch_client_modules) $(FINAL_NOTMUCH_LDFLAGS) -o $@ notmuch.1.gz: notmuch.1 gzip --stdout $^ $@ -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/4] Fix up Makefile for build.
Must set extra_c(xx)flags before including subdir Makefile.local's, so that there is a blank slate that the subdirs can add on to. Must include subdir Makefile.local's before global one, otherwise the compat sources are not added to the list of those to be compiled. Signed-off-by: Aaron Ecay aarone...@gmail.com --- Makefile |9 - Makefile.local|5 - compat/Makefile.local |2 +- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 076efc7..faaaec6 100644 --- a/Makefile +++ b/Makefile @@ -9,6 +9,13 @@ subdirs = compat completion emacs lib global_deps = Makefile Makefile.local \ $(subdirs:%=%/Makefile) $(subdirs:%=%/Makefile.local) +# Sub-directory Makefile.local fragments can append to these variables +# to have directory-specific cflags as necessary. + +extra_cflags := +extra_cxxflags := + # Finally, include all of the Makefile.local fragments where all the # real work is done. -include Makefile.local $(subdirs:%=%/Makefile.local) + +include $(subdirs:%=%/Makefile.local) Makefile.local diff --git a/Makefile.local b/Makefile.local index 9e753cd..c04044c 100644 --- a/Makefile.local +++ b/Makefile.local @@ -33,11 +33,6 @@ Makefile.config: configure @echo ./configure -# Sub-directory Makefile.local fragments can append to these variables -# to have directory-specific cflags as necessary. -extra_cflags := -extra_cxxflags := - # Smash together user's values with our extra values FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) diff --git a/compat/Makefile.local b/compat/Makefile.local index 81e6c70..50f6cd1 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -3,7 +3,7 @@ dir := compat extra_cflags += -I$(dir) -notmuch_compat_srcs = +notmuch_compat_srcs := ifneq ($(HAVE_GETLINE),1) notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 4/4] Add CONFIGURE_LDFLAGS to the notmuch-shared buld command line.
Otherwise, symbol not found errors result on OS X. I am not sure this is the correct solution for the problem, but it gets the build working. Signed-off-by: Aaron Ecay aarone...@gmail.com --- Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index 99d5b64..8d5fda4 100644 --- a/Makefile.local +++ b/Makefile.local @@ -36,7 +36,7 @@ Makefile.config: configure # Smash together user's values with our extra values FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(CONFIGURE_LDFLAGS) FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) .PHONY: all -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Use of strcasestr
--- 2010ko Apirilak 12an, Tomas Carnecky-ek idatzi zuen: Adding that function to compat/ probably is the way to go, but the whole compat mechanism doesn't work here. It's like if compat/Makefile.local was not included in the top-level makefile, notmuch_compat_srcs is empty there. Any ideas how to debug that? If you are referring to the bug I think you are, I sent a patch to the list to fix it yesterday. id:1271029494-89014-2-git-send-email-aarone...@gmail.com Aaron ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
segfault: g_type_init() missing
Dear all, I just pulled the last couple weeks' worth of changes and rebuilt notmuch, only to have the new binary give a segfault on notmuch new (running on OS X.6). The error message printed was: (process:21821): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init() And the backtrace (from gdb): #0 0x000a18f7 in g_object_newv () #1 0x000160e4 in notmuch_filter_discard_uuencode_new () #2 0x000163f0 in _index_mime_part () #3 0x0001667a in _notmuch_message_index_file () #4 0x0001247c in notmuch_database_add_message () #5 0x65a9 in add_files_recursive () #6 0x612c in add_files_recursive () #7 0x612c in add_files_recursive () #8 0x71ec in notmuch_new_command () #9 0x3a5a in main () According to the Glib docs (http://developer.gnome.org/gobject/unstable/gobject-Type-Information.html#g-type-init), the g_type_init() function must be called before using any GType stuff, which notmuch_filter_discard_uuencode_new does. There are no grep hits for g_type_init in the notmuch sources, though. The code on the error path looks pretty old, so I'm not sure why this bug hasn't hit someone else before. Adding a call to g_type_init() to main() (right after g_mime_init(0)) fixes the problem. Aaron ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add missing call to g_type_init()
Signed-off-by: Aaron Ecay aarone...@gmail.com --- notmuch.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/notmuch.c b/notmuch.c index 3973e35..f9d6629 100644 --- a/notmuch.c +++ b/notmuch.c @@ -579,6 +579,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); g_mime_init (0); +g_type_init (); if (argc == 1) return notmuch (local); -- 1.7.6 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add missing call to g_type_init()
The Glib docs state Prior to any use of the type system, g_type_init() has to be called.[1] To not do so can lead to segfaults. The g_type system is currently used by various filters that operate on uuencoded text, message headers, etc. [1] http://developer.gnome.org/gobject/2.28/gobject-Type-Information.html#g-type-init --- I have added a link to the Glib docs to the commit message, and a description of where the type code is used. There isn't an easy way to test for this bug, I think -- not including the init call is wrong by the API docs, but only sometimes yields a crash. notmuch.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/notmuch.c b/notmuch.c index 3973e35..f9d6629 100644 --- a/notmuch.c +++ b/notmuch.c @@ -579,6 +579,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); g_mime_init (0); +g_type_init (); if (argc == 1) return notmuch (local); -- 1.7.6 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] [emacs] Add an argument to notmuch-mua-mail
From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a rest argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmu...@gmail.com on Aug. 1: id:877h6x6oor@veracitynetworks.com Signed-off-by: Aaron Ecay aarone...@gmail.com --- emacs/notmuch-mua.el |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..23552ad 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -125,7 +125,8 @@ list. (message-goto-to)) (defun notmuch-mua-mail (optional to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action rest ignored) Invoke the notmuch mail composition window. (interactive) @@ -139,7 +140,8 @@ list. (notmuch-user-name) (notmuch-user-primary-email) )) other-headers)) (message-mail to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] [emacs] Add an argument to notmuch-mua-mail
From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a rest argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmu...@gmail.com on Aug. 1: id:877h6x6oor@veracitynetworks.com --- The previous version of this patch would break older emacsen. Not passing the return-action argument through to message-mail isn't nice, but the alternative is to conditionally pass it based on the emacs version, which is less nice. Thanks for the review Dmitry and Tomi. emacs/notmuch-mua.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..da31fdd 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -125,7 +125,8 @@ list. (message-goto-to)) (defun notmuch-mua-mail (optional to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action rest ignored) Invoke the notmuch mail composition window. (interactive) -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] [emacs] Add an argument to notmuch-mua-mail
From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a rest argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmu...@gmail.com on Aug. 1: id:877h6x6oor@veracitynetworks.com --- This version of the patch adopts Dmitry's arg-passing approach, and also cleans up a long line (it is still slightly over 80 chars as I didn't see a better way to break it). Tomi, I don't see two interactive calls -- I think Emacs would complain if this happened. emacs/notmuch-mua.el | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..510c951 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -124,9 +124,10 @@ list. (message-goto-to)) -(defun notmuch-mua-mail (optional to subject other-headers continue - switch-function yank-action send-actions) - Invoke the notmuch mail composition window. +(defun notmuch-mua-mail (optional to subject other-headers rest other-args) + Invoke the notmuch mail composition window. + +OTHER-ARGS are passed through to `message-mail'. (interactive) (when notmuch-mua-user-agent-function @@ -135,11 +136,11 @@ list. (push (cons User-Agent user-agent) other-headers (unless (mail-header 'from other-headers) -(push (cons From (concat - (notmuch-user-name) (notmuch-user-primary-email) )) other-headers)) +(push (cons From + (concat (notmuch-user-name) (notmuch-user-primary-email) )) + other-headers)) - (message-mail to subject other-headers continue - switch-function yank-action send-actions) + (apply #'message-mail to subject other-headers other-args) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] [emacs] Add an argument to notmuch-mua-mail
From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a rest argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmu...@gmail.com on Aug. 1: id:877h6x6oor@veracitynetworks.com --- emacs/notmuch-mua.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..b525762 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -124,9 +124,10 @@ list. (message-goto-to)) -(defun notmuch-mua-mail (optional to subject other-headers continue - switch-function yank-action send-actions) - Invoke the notmuch mail composition window. +(defun notmuch-mua-mail (optional to subject other-headers rest other-args) + Invoke the notmuch mail composition window. + +OTHER-ARGS are passed through to `message-mail'. (interactive) (when notmuch-mua-user-agent-function @@ -138,8 +139,7 @@ list. (push (cons From (concat (notmuch-user-name) (notmuch-user-primary-email) )) other-headers)) - (message-mail to subject other-headers continue - switch-function yank-action send-actions) + (apply #'message-mail to subject other-headers other-args) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Give a path name to mktemp in Makefile.local
On some systems (incl. OS X 10.6), mktemp expects an argument giving it the place to put the new temporary file. --- On my machine without this patch, make prints a message from mktemp about expecting an argument each time it is run. At some point, make got into a situation where it would print this message and exit cleanly, but not build any changed files. A make clean was necessary to kick it into working again. A disadvantage of this approach is that it drops an empty file into /tmp on every make run. It would be better to only create this file when doing make debian-snapshot, but I am not sure how to do that (cleanly; my best idea is to put the build commands into a subshell and export an environment variable for the temp file). Any make/debian experts want to take a stab? Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index c94402b..6eb4b18 100644 --- a/Makefile.local +++ b/Makefile.local @@ -139,7 +139,7 @@ pre-release: mv $(TAR_FILE) $(DEB_TAR_FILE) releases .PHONY: debian-snapshot -debian-snapshot: TMPFILE := $(shell mktemp) +debian-snapshot: TMPFILE := $(shell mktemp /tmp/notmuch.XX) debian-snapshot: make VERSION=$(VERSION) clean cp debian/changelog $(TMPFILE) -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Ignore dynamic libraries on OS X.
Parallel to ignoring .so for linux. --- .gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 9468e30..d64ec9f 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ notmuch.sym notmuch-shared notmuch.1.gz libnotmuch.so* +libnotmuch*.dylib *.[ao] *~ .*.swp -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Give a path name to mktemp in Makefile.local
On Sat, 17 Dec 2011 13:20:41 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Not that I'm saying we shouldn't fix this issue, but just out of curiosity, under what circumstances would someone want to call the debian-snapshot target from a non-debian based system? That part of the makefile is called unconditionally, on all systems. So it doesn't matter if one does make debian-snapshot or not, the error is still generated. -- Aaron Ecay ___ 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
[PATCH] emacs: fix off-by-one bug in notmuch-show-archive
Text properties change between characters; prev-s-c-property-change returns the position after the change. Thus, it is still inside the invisible region. --- emacs/notmuch-show.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f52f233..905c9ec 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1169,8 +1169,9 @@ current window), advance to the next open message. (ret nil)) (while (invisible-p visible-end-of-this-message) (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) + (max (point-min) +(1- (previous-single-char-property-change + visible-end-of-this-message 'invisible) (cond ;; Ideally we would test `end-of-this-message' against the result ;; of `window-end', but that doesn't account for the fact that -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
David, Would the problem you had with previous-s-c-prop-change be fixed by the patch to the original function I sent in the thread starting at id:m2y5u5cykp@kcals.intra.maillard.im ? -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH v4] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]. -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'. (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message start-of-window) - ( start-of-message start-of-window)) + ((= start-of-message (point)) + ;; The cursor is at the start of the current message - move to + ;; the previous open message. + (notmuch-show-previous-open-message)) This will jump to the beginning of the previous message if I'm at the beginning of a message. I would expect rewind to show me the end of the previous message in this case. Agreed. I would like to see this case move back one screenful of text or to the previous beginning-of-message, whichever is shorter. Something like this should do the trick (replacing the notmuch-show-prev-msg call): (let ((last-msg-point (save-excursion (notmuch-show-goto-message-previous) (point (scroll-down) (if ( last-msg-point (window-start)) (goto-char last-msg-point) (goto-char (window-start))) (notmuch-show-message-adjust)) Thanks, -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Don't signal an error when reaching the end of the search results.
On Tue, 20 Dec 2011 08:45:14 +, David Edmondson d...@dme.org wrote:
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.
+1 from me on this change. I had added this to `debug-ignored-errors'
long ago, and forgotten how annoying it was.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner da...@tethera.net wrote: I think the problem is related to emacsclient. With 'm' I have the following behaviour: emacs -q --daemon M-x notmuch (to load variable definitions) M-x customize-variable notmuch-mua-compose-in (select compose in new window, save for current session) M-x notmuch m ;; new window is opened as it should be C-c C-c ;; frame is closed. I just tried, and I cannot reproduce this behavior. IIUC, here is what happened to you: you set nm-mua-compose-in to 'new-window. You began a new message, this opened a new window as expected. Your emacs frame now has two windows in it. You sent this message, which deleted the window showing it. Your emacs frame was deleted as well, which made the other window, showing notmuch-hello (or some other notmuch buffer, from which you began writing the email message) disappear as well, unexpectedly. Is this a correct description of what happened? Here’s the recipe I used for replicating: emacs -q --daemon emacsclient -c C-x b *scratch* (add-to-list 'load-path /path/to/notmuch/emacs/) C-j (load-library notmuch) C-j C-x C-f /path/to/notmuch/emacs/notmuch-mua.el M-x eval-buffer (in order to pick up changes not in byte-compiled file) M-x customize-variable notmuch-mua-compose-in (set to 'new-window, save for session) M-x notmuch m (new window is created in current frame, below the window showing notmuch-hello) (type mail) C-c C-c (enter smtp settings, since emacs doesn’t know them) (new window disappears, the window with notmuch-hello fills whole frame) I also tried with notmuch-mua-compose-in set to 'new-frame, and got the expected behavior (m - create new frame, C-c C-c - new frame is deleted) What version of emacs did you have this problem with? The window/frame handling code has undergone several intrusive rewrites post-v.23, each of which fixed some bugs and introduced others. The version I used is a trunk build from Dec. 12-ish. It would be nice to pinpoint which emacs versions/configurations show undesired behavior – this is a useful patch and it should be included once we can be sure it will work correctly. Thanks, -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH v4] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
On Wed, 28 Dec 2011 15:22:45 +, David Edmondson d...@dme.org wrote: I thought about this a bit more (mostly because I don't want to write tests for one behaviour and then have to change them - writing tests for emacs with the current test suite is painful). If you want to go back a page you can use M-v. The whole point of binding DEL to something in `notmuch-show-mode' is that it implement something other than the vanilla behaviour. Simply showing the previous page (the equivalent of M-v) adds no value. If you want to jump back to the previous message, you can press `p'. (And M-v is a chord whereas DEL and p are a simple keystroke, so it’s arguably maximally convenient to duplicate a chord command on a single key rather than duplicating a single key on another single key.) The way I look at it, notmuch has two sets of movement keys – n/p and SPC/DEL. The former moves by messages, and the latter by screenfuls (with the added complication that the screenful movement commands also stop at intervening message boundaries). I’d prefer to maintain that symmetry. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] emacs: unify search mechanisms
On Fri, 30 Dec 2011 10:43:37 -0400, David Bremner da...@tethera.net wrote: Personally I would like to be able to customize the hello screen to remove the search box. I find it confusing that that 's' jumps to the search box there, and everywhere else brings up the mini-buffer. +1. I rarely use notmuch-hello, but when I do, I press `s' then look to the bottom of the screen and am always confused not to see a minibuffer prompt. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Update NEWS for change by Aaron Ecay
--- NEWS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index eaed960..3688944 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,16 @@ Automatic tag query optimization exclude messages whose tags won't change. In the past, we've suggested that people do this by hand; this is no longer necessary. +Emacs interface +--- + +Bug fixes + + notmuch-show-advance (bound to the spacebar in notmuch-show-mode) had + a bug that caused it to always jump to the next message, even if it + should have scrolled down to show more of the current message instead. + This is now fixed. + Notmuch 0.10.2 (2011-12-04) === -- 1.7.8.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Calls to notmuch get queued and executed asynchronously.
On Fri, 30 Dec 2011 10:52:17 +, David Edmondson d...@dme.org wrote: I discovered this patch a while ago and it almost applies cleanly (the conflicts are easy to fix though) and it has made the emacs UI for notmuch _much_ more responsive and enjoyable for me. This is definitely true for me as well. So much so that I reinvented this patch from scratch a couple of weeks ago. (As Picasso said, good artists copy, great artists steal.) As discussed on IRC, issues such as where to handle retries in case the database is locked should probably be handled in the notmuch binary instead of each UI. Hmm. When my implementation detects that it cannot get the DB lock after trying several times (up to ~2 mins of waiting), it stops trying but continues to queue up operations. The user can then manually restart the queue. This isn’t a principled solution, but it avoids losing tagging operations from emacs while a long-running process has the DB locked. (My original motivation for writing the patch was actually that my new-mail script sometimes holds the DB lock when I am trying to read mail, leading to emacs errors and dropped tagging operations. The speedup was a welcome side effect.) I haven’t had a chance to carefully look at the patch you found, so IDK what its behavior would be in this case. (The other thing that I dislike about the patch you found is that it uses a call to the “sleep” command to wait, rather than using built-in emacs functionality.) It would be good to have an updated version of this patch if it is still considered useful, though I don't suffer particularly from lag in the emacs UI. The emacs UI has small delays, which dropped away when I applied my version of this patch. After being conditioned to expect them, I was surprised to find how much faster everything seemed. My hardware is old but not ancient (5.5 year old Macbook; I suspect the bottleneck for notmuch is the 5400rpm HDD). Depending on your setup, you too might be pleasantly surprised. The test suite is borked on OS X and I don’t have access to a linux machine while traveling. I was planning on sending my patch in early Jan. when I had a chance to verify it under the test suite (probably requiring some changes to the emacs test library to make it async-safe). I also haven’t tested the patch on Emacs versions older than 24 – but I don’t think there are any impediments to compatibility with v.23 (not sure about earlier versions). Since there is interest, I’ll go ahead and send it now with all the usual caveats about code under development. I have been using the patch for a couple of weeks without problems, though. Daniel, if you want to un-conflict (and squash) the patches from James that might be useful, at least to compare the two approaches. Aaron -cut-here- From f0a0fe04254d9b5e17c873b293c6a5a270cb909a Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Mon, 19 Dec 2011 12:14:31 -0500 Subject: [PATCH] [emacs] add async tagging support still a WIP --- emacs/notmuch.el | 55 +- 1 files changed, 54 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index fde2377..ca077c2 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -446,6 +446,59 @@ Complete list of currently available key bindings: (let ((message-id (notmuch-search-find-thread-id))) (notmuch-mua-new-reply message-id prompt-for-sender))) +(defvar notmuch-process-queue nil + Queue of pending notmuch tag operations. + +Each entry in the queue is a list of strings, which are arguments +to be passed to the notmuch command.) + +(defvar notmuch-process-current-command nil + The currently executing notmuch command arguments) + +(defvar notmuch-process-wait-time 1.0 + How long to wait for the db lock, in seconds.) + +(defvar notmuch-process-error nil) + +(defun notmuch-process-restart-queue () + (interactive) + (setq notmuch-process-error nil) + (notmuch-process-kick-queue)) + +(defun notmuch-process-kick-queue () + (when notmuch-process-error +;; TODO: better error msg, tell how to manually kick +(error Notmuch couldn't get the DB lock after trying for more than a minute.)) + (when (and notmuch-process-queue +(memq (process-status notmuch) '(exit nil))) +(let ((args (car notmuch-process-queue)) + proc) + (setq notmuch-process-queue (cdr notmuch-process-queue) + notmuch-process-current-command args + proc (apply #'start-process notmuch + (get-buffer-create *Notmuch output*) + notmuch-command args)) + (set-process-sentinel proc #'notmuch-process-sentinel + +(defun notmuch-process-sentinel (proc status) + (if (equal status finished\n) + (progn + (setq notmuch-process-wait-time 1.0 + notmuch-process-current-command nil) + (notmuch-process-kick-queue)) +(setq notmuch-process-wait
Re: [PATCH] Update NEWS for change by Aaron Ecay
On Fri, 30 Dec 2011 22:54:30 -0400, David Bremner da...@tethera.net wrote: pushed, although I had to mess with it a fair amount. Maybe it was against master, rather than release? It was. I didn’t realize that the patch should be against the release branch; sorry about that... :-| -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call notmuch tag only once when archiving a thread
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula j...@nikula.org wrote: Optimize thread archiving by combining all the -inbox tagging operations to a single notmuch tag call. Perhaps I’m missing something, but is there anything preventing emacs from just doing the following? notmuch tag -inbox thread:000whatever -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: call notmuch tag only once when archiving a thread
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula j...@nikula.org wrote: [...] In the show view it only modifies the messages that are currently visible. This is to make sure you don't accidentally archive things that have arrived after refreshing the buffer. I think this is safest. Hmm. Perhaps it would make sense to add a check in the search view that the thread being archived[1] has the same number of messages as it did when the buffer was constructed. (The information on how many messages the thread has is in the buffer; we would then compare this to the result of “notmuch count thread:000foo” when the user requests to archive.) If the counts don’t match, the interface should show a message in the echo area and (probably) refuse to do the tagging. We could also optionally use this strategy in the search view too. The error message is simple there: “New messages have arrived; refresh thread view before archiving.” (It doesn’t make as much sense to tell people to refresh a search view – it could be an expensive operation and/or may not be idempotent if some thread’s tags have been changed. So it’s harder to say what the advice should be in that case.) If other people think it would be useful, I can work on a patch to implement this approach. Footnotes: [1] Or having its tags changed generally. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
Jameson, Some comments below: On Sat, 7 Jan 2012 14:28:12 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Instead of having a function that is only used for archiving a thread, we instead make it useful for any tagging operation. The new function, notmuch-show-tag-thread-internal, now takes two more arguments, for the sign of the tagging operation (- or +), and the tag to be added or removed. This will allow this function to be used for any generic thread tagging operation. The higher level functions that call this function are modified accordingly. --- emacs/notmuch-show.el | 34 -- 1 files changed, 20 insertions(+), 14 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 5502efd..1e16f05 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1414,20 +1414,26 @@ argument, hide all of the messages. (interactive) (backward-button 1)) -(defun notmuch-show-archive-thread-internal (show-next) +(defun notmuch-show-tag-thread-internal (sign tag show-next) A couple of comments on the arguments: - It would be good to make show-next optional. This will enable code to call the fn with only two arguments, and not showing next will be the default behavior. - A more lispy way of specifying the sign would be to use a boolean. Perhaps you could call this “remove”; a value of ‘t’ would remove the tag; ‘nil’ would add it. Moving this argument after ‘tag’ and also making it optional woudl allow this fn to be called with one arg to add a tag. (Maybe this is too minimalist and API, however.) ;; Remove the tag from the current set of messages. (goto-char (point-min)) - (loop do (notmuch-show-remove-tag inbox) - until (not (notmuch-show-goto-message-next))) - ;; Move to the next item in the search results, if any. - (let ((parent-buffer notmuch-show-parent-buffer)) -(notmuch-kill-this-buffer) -(if parent-buffer - (progn - (switch-to-buffer parent-buffer) - (forward-line) - (if show-next - (notmuch-search-show-thread)) + (let ((tag-function)) No second set of parens is needed around tag-function. +(cond + ((string= sign -) + (setq tag-function 'notmuch-show-remove-tag)) + ((string= sign +) + (setq tag-function 'notmuch-show-add-tag))) +(loop do (funcall tag-function tag) + until (not (notmuch-show-goto-message-next))) +;; Move to the next item in the search results, if any. Does it make sense to separate the tagging and the movement? It seems plausible that some code somewhere might want to add/remove a tag from all messages in the thread w/o changing the display. +(let ((parent-buffer notmuch-show-parent-buffer)) + (notmuch-kill-this-buffer) + (if parent-buffer + (progn + (switch-to-buffer parent-buffer) + (forward-line) + (if show-next + (notmuch-search-show-thread))) -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/4] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end
Jameson, One small, stylistic/nitpicky comment :) On Sat, 7 Jan 2012 17:26:53 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: This will allow for keybindings that achieve a smoother message processing flow by reducing the number of key presses needed for most common operations. --- emacs/notmuch-show.el | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 8bb052e..e7bb958 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1264,17 +1264,23 @@ any effects from previous calls to (notmuch-show-mark-read) (notmuch-show-message-adjust)) -(defun notmuch-show-next-open-message () +(defun notmuch-show-next-open-message (optional pop-at-end) Show the next message. (interactive) - (let (r) + (let ((r) + (parent-buffer notmuch-show-parent-buffer)) No second set of parentheses is needed around r. Also, it is more idiomatic to put the initialized variable (i.e. parent-buffer) before the uninitialized one (r). (while (and (setq r (notmuch-show-goto-message-next)) (not (notmuch-show-message-visible-p (if r (progn (notmuch-show-mark-read) (notmuch-show-message-adjust)) - (goto-char (point-max) + (if (and parent-buffer pop-at-end) + (progn + (kill-this-buffer) + (switch-to-buffer parent-buffer) + (forward-line 1)) + (goto-char (point-max)) (defun notmuch-show-previous-open-message () Show the previous message. -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] emacs: new customization variable to exclude deleted messages from search
Jameson, One comment On Sat, 7 Jan 2012 14:28:11 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: The new customization variable, notmuch-search-exclude-deleted, when set to t, will exclude any messages with the deleted tag from searches. Additionally, specifying tag:deleted in the search directly will override the exclusion and will included deleted messages in the search results. --- emacs/notmuch.el |8 test/emacs | 42 .../notmuch-search-tag-inbox-deleted-excluded | 24 +++ 3 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 test/emacs.expected-output/notmuch-search-tag-inbox-deleted-excluded diff --git a/emacs/notmuch.el b/emacs/notmuch.el index fde2377..c519687 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -905,6 +905,11 @@ PROMPT is the string to prompt with. (read-from-minibuffer prompt nil keymap nil 'notmuch-query-history nil nil +(defcustom notmuch-search-exclude-deleted nil + Exclude deleted messages (with \deleted\ tag) from search results. + :group 'notmuch + :type 'boolean) + ;;;###autoload (defun notmuch-search (query optional oldest-first target-thread target-line continuation) Run \notmuch search\ with the given query string and display results. @@ -927,6 +932,9 @@ The optional parameters are used as follows: (set 'notmuch-search-target-thread target-thread) (set 'notmuch-search-target-line target-line) (set 'notmuch-search-continuation continuation) +(when (and notmuch-search-exclude-deleted +(not (string-match tag:deleted[ )]* query))) “is:” is a synonym for “tag:” in searches – so this section of the code should look for it too. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/4] emacs: Use the new JSON reply format.
Adam, One comment below. On Sun, 8 Jan 2012 00:52:42 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: From: Adam Wolfe Gordon a...@xvx.ca Using the new JSON reply format allows emacs to quote HTML parts nicely by first parsing them with w3m, then quoting them. This is very useful for users who regularly receive HTML-only email. The behavior for messages that contain plain text parts should be unchanged, except that an additional quoted line is added to the end of the reply message. The test has been updated to reflect this. --- emacs/notmuch-mua.el | 62 +++-- test/emacs |1 + 2 files changed, 50 insertions(+), 13 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 7114e48..7f894cb 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -19,6 +19,7 @@ ;; ;; Authors: David Edmondson d...@dme.org +(require 'json) (require 'message) (require 'notmuch-lib) @@ -71,27 +72,62 @@ list. (push header message-hidden-headers))) notmuch-mua-hidden-headers)) +(defun w3m-region (start end)) ;; From `w3m.el'. What is the purpose of the above line? If it is to make the compiler aware of the function, you should use ‘declare-function’ instead. Defun will erase the original definition of the w3m-region function. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
On Sun, 8 Jan 2012 00:52:38 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: [...] There should probably be some customize variables for this in emacs, to control (for example) whether to quote HTML parts and whether to prefer HTML or plaintext parts for quoting. Any suggestions for what should be customizable would be appreciated. I think two variables should suffice: one (boolean) to control whether to quote standalone text/html parts, and one to control which parts of a multipart/alternative part to quote. The latter should take possible values 'text, 'html, and 'both. This requires the emacs reply functionality to distinguish between html parts that are part of a multipart/alternative and those which are not, which (AFAICT) the current code doesn’t do. I haven’t tested the patch yet, but it looks very promising. Thanks! -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Thanks so much for the review, Aaron.
On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay aarone...@gmail.com wrote:
A couple of comments on the arguments:
- It would be good to make show-next optional. This will enable code
to call the fn with only two arguments, and not showing next will be
the default behavior.
That's a nice idea. Probably better for a separate patch, though.
This patch introduces show-next as a new argument to the function. So it
can and should make it optional, if that is the appropriate semantics
for it to have.
- A more lispy way of specifying the sign would be to use a
boolean. Perhaps you could call this “remove”; a value of ‘t’ would
remove the tag; ‘nil’ would add it. Moving this argument after ‘tag’
and also making it optional woudl allow this fn to be called with one
arg to add a tag. (Maybe this is too minimalist and API, however.)
That might be more lispy, but it seems a lot less clear to me. It might
save a few keystrokes when coding, but it would definitely make the code
a lot harder to read (remove to add a tag?). I think I would prefer
people to give the sign explicitly.
Using a string value makes it harder to interface with other code. For
example, the prefix argument (C-u) is delivered to emacs commands as a
boolean value (nil if no arg, something truthy if the arg is given). A
plausible custom end user function/keybinding would be one to add a tag
to the open messages, or remove that tag if the prefix arg is given to
the same command. (So that ‘d’ deletes and ‘C-u d’ undeletes, for
example.) In order to do that, the user’s code has to convert the
prefix arg into a string. Making something “lispy” isn’t just about
code readability/saving keystrokes, but also refers to how well the
code interfaces with the conventions used by the rest of the emacs
environment.
That said, here’s an alternate proposal: provide two functions as the
“external” API, namely ‘notmuch-show-{add,remove}-tag-thread’ (by
parallelism with ‘notmuch-show-{add,remove}-tag’). These could be
thin wrappers around ‘notmuch-show-tag-thread-internal’, which would
then not be intended to be called by user code.
No second set of parens is needed around tag-function.
Yeah, I've seen this either way. I guess it's just a stylistic
choice.
Using double parens is semantically correct, but makes the code less
idiomatic and harder to read (IMO). To test my intuition, I looked at
‘let’ invocations in the Emacs source that have a non-initialized
variable (because the multiple variable case is hard to grep for).
Double parens are used only 3% of the time (44 double vs 1468 single).
Make of this data what you will.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Actually, the show-next argument was already part of the function. I did not introduce it. And it wasn't optional originally, so if we want to change that behavior we should probably do so in a separate patch. Hrm. I didn’t communicate as clearly as I could have – you are correct that the show-next argument to the notmuch-show-archive-internal function was pre-existing. But notmuch-show-tag-thread-internal is a new function, with potentially expanded usefulness to third-party code. Thus I think I’m in the clear to bikeshed about its calling convention. :) It’s your patch, though, so it’s your call if you feel that the optional goes best in a new change. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
On Sun, 15 Jan 2012 09:26:59 +, David Edmondson d...@dme.org wrote: Given that we're now doing a bunch of work in emacs as part of the reply setup, why not just grab the content of the original message from the show buffer and quote that? The last time that approach was discussed Carl was against it because it moved the emacs UI away from the behaviour of the CLI, but it seems that we're already heading in that direction. I have been watching this patch series with interest, because it seemed that when it landed it would be a good time for me to begin work on a patch to allow notmuch to function like other emacs MUAs in constructing the reply buffer internally to emacs, rather than through notmuch. This allows (at least) three things: - Greater flexibility in the construction of address lists. For example, there are some email lists where I want replies to list mail to go only to the list, not also to the original sender. Additionally, I like to reply from my university address if colleagues write to my Gmail one. If a lisp function is generating the replies, it can be made to run a hook allowing users to insert these or other custom behaviors. - The same reasoning as above, applied to signatures. (different ones for different recipients) - There exists at least one emacs package (supercite) which allows customization of the quoting of email replies. This automates the “Firstname” style quotes one sometimes sees, as well as many other possiblities. It defines a way for emacs MUAs to construct reply buffers to cooperate with it, which many of the big emacs MUAs obey (Gnus and Wanderlust certainly do). This is explained in the “hints to MUA authors” section of the supercite manual (distributed with Emacs). So, a +1 from me on this idea, from a different perspective. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] v2 emacs: colorize buttonized 'id:' links depending on the target message's state
On Mon, 16 Jan 2012 17:57:33 +0100, Pieter Praet pie...@praet.org wrote: * emacs/notmuch-show.el (notmuch-show-buttonized-link-colors): new defcustom, allows toggling colorization of buttonized links. * emacs/notmuch-show.el (notmuch-show-buttonized-link-present), * emacs/notmuch-show.el (notmuch-show-buttonized-link-present-and-unread), * emacs/notmuch-show.el (notmuch-show-buttonized-link-missing): new faces for buttonized id: links. * emacs/notmuch-show.el (notmuch-show-found-target-p): add optional arg VERIFY-UNREAD which causes results to be filtered by tag:unread. * emacs/notmuch-show.el (notmuch-show-buttonize-links): use different face property depending on the result of `notmuch-show-found-target-p', causing buttons to available, available-and-unread and missing messages to be displayed in a different color. I really like the idea behind this patch, but it has the very small problem that it colorizes too much. So in reading this thread, there are things like “id:’s” and “id:?” that get colored the missing-message color (a very angry red, by default). Though this isn’t likely to be a very frequent problem with email messages that are not on this listserv :), it would be nice to fix it. Maybe you could change the regex that matches id:’s to require a little more structure – an at-sign, perhaps. Or even requiring more than (say) 5 non-space characters after the message id would cut down sharply on the false positive rate. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Truncate lines and do not enable visual-line-mode in notmuch-show buffers.
On Mon, 16 Jan 2012 14:13:22 +, David Edmondson d...@dme.org wrote: Enable the truncation of lines in `notmuch-show-mode' to avoid visual noise caused by the wrapping of the header lines. Don't enable `visual-line-mode' because it disables line truncation. The benefits of `visual-line-mode' were that it wrapped long lines in received messages. With `notmuch-wash-wrap-long-lines' now default behaviour, this is no longer required. +1 -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
On Mon, 16 Jan 2012 08:39:30 +, David Edmondson d...@dme.org wrote: On Mon, 16 Jan 2012 02:38:38 -0500, Aaron Ecay aarone...@gmail.com wrote: - Greater flexibility in the construction of address lists. For example, there are some email lists where I want replies to list mail to go only to the list, not also to the original sender. Is there a mechanistic way to determine the correct behaviour in this respect? I suspect that it's exactly the kind of thing that Carl wanted to be included in 'notmuch' itself, so that other UIs can benefit. I think it requires some amount of configuration, but it can be done sensibly. I am much more proficient with Elisp than with C, and Emacs has prejudiced me towards solutions that allow me to have a Turing-complete configuration language. :) I think a good starting point for thinking about mailing lists is what Mutt does: http://www.mutt.org/doc/manual/manual-4.html#using_lists Notmuch at the CLI/C code level could aim for a comparable level of expressiveness, and I think it would suffice for most people (including me). [...] You can do both of these things today using `message-send-hook' (I do). I avoided that, as it seemed to me that just before the message is sent is too late to be doing these things (I’d like to see confirmation when writing the message that the address/signature changes were applied correctly). But “M-x apropos RET message hook RET” shows that there are some earlier points to hook into as well. Thanks. I dislike supercite, so no support from me in that direction :-) One advantage of supercite is that it allows non-English speakers to set up the “On X, X wrote” line as they prefer. Notmuch’s current approach (a hard-coded C string) is the opposite of internationalized. So it would be nice to support some customization of that as well, even if we don’t go the supercite route. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Infinite loop in emacs interface
Rodney, After converting the mbox file to Maildir and adding it to my mailstore, I cannot reproduce the loop. (The versions of notmuch and emacs I used are close to the ones you have, but not an exact match, so it may be something subtle about those versions. I can investigate more carefully if it seems like this is the case.) If you do: M-x set-variable RET debug-on-quit RET t RET then trigger the loop and press C-g, you should get a buffer showing a backtrace of the lisp stack. What does that say? Thanks, -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: show-mode message/thread archiving improvements
+1 on this series from me. (Minor comments on a couple of the patches to follow.) -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions
On Tue, 17 Jan 2012 10:05:26 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Brake up notmuch-show-archive-thread-internal into two new functions:
notmuch-show-tag-thread-internal: applies a tag to all messages in
thread. If option remove flag is t, tags will be removed instead of
added.
notmuch-show-next-thread: moves to the next thread in the search
result. If given a prefix, will show the next result, otherwise will
just move to it in the search view.
Two new interactive functions, notmuch-show-{add,remove}-tag-thread,
are also added. Together, these provide a better suit of thread
tagging and navigation tools.
The higher level thread archiving functions are modified to use these
new functions.
---
emacs/notmuch-show.el | 33 ++---
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 03c1f6b..3625afd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1421,12 +1421,29 @@ argument, hide all of the messages.
(interactive)
(backward-button 1))
-(defun notmuch-show-archive-thread-internal (show-next)
- ;; Remove the tag from the current set of messages.
+(defun notmuch-show-tag-thread-internal (tag optional remove)
+ ;; Add tag to the current set of messages. If the remove switch is
+ ;; given, tags will be removed instead of added.
This should be a docstring instead of a comment. (This applies equally
to the old version)
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: have notmuch-search-archive-thread use -next-thread function
+1 -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] Make buttons for attachments allow viewing as well as saving
On Tue, 17 Jan 2012 15:26:03 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Mark Walters on Jan 17 at 9:06 am: I wonder if the problem comes from me doing things in a non-lispy fashion (I am completely new to lisp). Thus notmuch-show-part-button-default-action is a variable that gets passed around rather than a function. Sorry, I should have looked at the bigger context in this patch. I think Jameson was implying that notmuch-show-part-button-default should change to (defun notmuch-show-part-button-default (optional button) (interactive) (funcall notmuch-show-part-button-default-action button)) I would go one step further and say that each action should probably be a separate function. That is, break notmuch-show-part-action into separate functions and simply invoke the appropriate function, rather than performing a fixed data dispatch. This would be more flexible and Lispy. It may be that your approach works out better, but I'd at least give this a shot. I am happy to make that change. My original patch in the summer was more like that: id:caludzswato+4mcuoomk+8vfs+pog-xuma6u-aqx2m6-sbyq...@mail.gmail.com Is this the right id? I couldn't find it in the list archive. Is that more what you had in mind? (Only in broad terms: Obviously I would need to add in the customization and default function etc). I decided that I didn't like the code duplication (but I am completely new to lisp) which is why I changed it for this submission. Yes, I wondered about this, too. It seems like at worst the notmuch-show-process-crypto stuff would be duplicated. This might be little enough that it's not worth worrying about, or it might be worth introducing something like (defun notmuch-with-temp-part-buffer (message-id nth action) (let ((process-crypto notmuch-show-process-crypto)) (with-temp-buffer (setq notmuch-show-process-crypto process-crypto) ;; Always acquires the part via `notmuch part', even if it is ;; available in the JSON output. (insert (notmuch-show-get-bodypart-internal message-id nth)) (funcall action You could also do this as a macro, but that definitely seems like overkill. It seems to me that a macro is in fact the best solution. If you do it with a function, you need two defuns per action: one to do the actual work: (defun notmuch-show-part-button-whatever-worker () ;; do stuff... ) and one that says: (defun notmuch-show-part-button-whatever () (notmuch-with-temp-part-buffer id part-number #'notmuch-show-part-button-whatever-worker)) It would be the latter function that the key would be bound to. If a macro is used, the split between the worker and glue fns can be abandoned, and only one function is needed: (defun notmuch-show-part-button-whatever () (notmuch-with-temp-part-buffer ;; do stuff... )) A further advantage is if interactive arguments (e.g. C-u prefix) are needed for the function, there is no need to thread them through as arguments of notmuch-with-temp-part-buffer. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions
On Tue, 17 Jan 2012 12:17:54 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: We're not currently in the habit of adding doc strings for non-interactive programs. Do we need to go down that route? It is handy for developers, since the usual documentation facilities (describe-function, apropos, ...) will then work for that function too. Emacs documentation recommends(-ish) this: ,[ Elisp manual Section D.6 ] | An internal variable or subroutine of a Lisp program might as well | have a documentation string. In earlier Emacs versions, you could | save space by using a comment instead of a documentation string, | but that is no longer the case--documentation strings now take up | very little space in a running Emacs. ` -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Improved printing support.
On Wed, 18 Jan 2012 08:00:21 +, David Edmondson d...@dme.org wrote:
Add various functions to print notmuch messages and tie them together
with a simple frontend.
Add a binding ('#') in `notmuch-show-mode' to print the current
message.
---
Updates based on Aaron's review - the comments were very useful in
improving things - thanks!
You’re welcome! The patch LGTM.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'
On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet pie...@praet.org wrote: My original intent of conserving a key(chord) [1] (which in retrospect was a fairly pointless exercise in and of itself [2,3]) seems to have inconspicuously morphed into an equally questionable crusade [4] against the `cl' package. As long there's other functions in Notmuch depending on compile-time `cl', there's really no incentive whatsoever to replace your perfectly fine solution. (This is not strictly related to the immediate issue of these patches, but now seems as good a time as any to discuss it.) Compile-time dependencies on ‘cl’ are absolutely not a problem. Virtually every major elisp program depends on cl at compile time. Runtime dependencies are not allowed in code distributed with emacs because of RMS’s conservativism[1]. Since notmuch isn’t distributed with emacs and has no aspirations to ever be, the project could decide to require cl at runtime. Many elisp programs do. (A quick grep through my .emacs.d folder turns up anything.el and clojure-mode as two large/“mainstream” projects that do, as well as at least a dozen smaller utility files.) So many emacs users have cl loaded all the time when they are using emacs. But unless the project (i.e. us) decides explicitly “runtime cl is OK” (or perhaps “it is not”), contributors will always go back and forth over using it. To avoid patch and review churn, we ought to decide which of these we pick (and I vote for allowing runtime use.) Aaron Footnotes: [1] He specifically objects to the way that the cl package uses keyword arguments, calling it un-Elisp-like. He has resisted past efforts to merge cl functions into Elisp core, although they are slowly diffusing across the barrier. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Quote MML tags in replies
Emacs message-mode uses certain text strings to indicate how to attach files to outgoing mail. If these are present in the text of an email, and a user is tricked into replying to the message, the user’s files could be exposed. --- To demonstrate this, open a reply to this message then remove the exclamation marks after the hash marks below. Create a file in your home directory called passwd. Then press C-u M-x mml-preview. A (possibly base64-encoded) version of your ~/passwd file will replace the following lines: #!part type=application/octet-stream filename=~/passwd disposition=attachment description=foo #!/part It works equally well (and more dangerously) with /etc/passwd, but I didn't use that filename here to avoid the danger of someone accidentally attaching their /etc/passwd to a reply in this thread! emacs/notmuch-mua.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index d8ab822..c25c6b9 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -115,7 +115,8 @@ list. (push-mark)) (set-buffer-modified-p nil) - (message-goto-body)) + (message-goto-body) + (mml-quote-region (point) (mark))) (defun notmuch-mua-forward-message () (message-forward) -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply
On Thu, 19 Jan 2012 10:46:57 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: Instead of using a static citation line for the first line of the reply message, use the customizable one defined by message-mode. This makes it easy for users to customize the reply style, and retains consistency for users with existing message-mode customizations. --- emacs/notmuch-mua.el | 19 --- test/emacs |2 +- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 5ae0ccf..e485d93 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -134,9 +134,22 @@ list. (forward-line -1) (goto-char (point-max))) - (insert (format On %s, %s wrote:\n - (cdr (assq 'date original-headers)) - (cdr (assq 'from original-headers + (let* ((quoth message-citation-line-format) + (case-fold-search nil) + (full-from (cdr (assq 'from original-headers))) + (from-addr (car (mail-header-parse-address full-from))) + (from-name (cdr (mail-header-parse-address full-from))) + (first-name (car (split-string from-name))) + (last-name (append (cdr (split-string from-name + (time (date-to-time (cdr (assq 'date original-headers) + + (setq quoth (replace-regexp-in-string %f full-from quoth t t)) + (setq quoth (replace-regexp-in-string %n from-addr quoth t t)) + (setq quoth (replace-regexp-in-string %N from-name quoth t t)) + (setq quoth (replace-regexp-in-string %F first-name quoth t t)) + (setq quoth (replace-regexp-in-string %L last-name quoth t t)) + (setq quoth (format-time-string quoth time)) + (insert quoth)) Shouldn’t this just use message-insert-formatted-citation-line? Another approach you might take with this patch series is to look at the message-cite-original function (which I just discovered as I was plumbing around in message.el looking for the function to format the citation line). I think that what one does to use this fn is to put the original message text into the reply buffer (unquoted), set point and mark to encompass it, then call the fn. It automatically handles inserting the quotes, and has some customization options (stripping signatures from replies, customizable quote character instead of “”, ...). The message-cite-original function also adds escape characters to the cookies that message-mode uses to indicate sign/encrypt/attach directives. I think notmuch exposes files on the user’s computer to others, if a user can be tricked into replying to a message with an attachment cookie and not stripping the cookie from the reply text. So to mitigate this, whatever reply mechanism winds up being used should call mml-quote-region on the reply text (as message-cite-original does). I just sent a patch to the list to do this in the current version of notmuch, which should show up in id:1326998589-37187-1-git-send-email-aarone...@gmail.com . -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 2/2] search: Support automatic tag exclusions
On Thu, 19 Jan 2012 20:06:27 +, markwalters1...@gmail.com wrote: I would actually like make a different suggestion: extend auto_exclude_tags to notmuch-show as well. I was quite surprised to see my deleted (ie hidden rather than actually deleted) messages return when viewing a thread. It might be best to show the messages in the thread – after all, you might want to “undelete” (or “unspam”) those messages in light of later replies to them. (And if you are sure you really want them gone, you should be deleting them or moving them out of your maildir periodically, rather than relying on notmuch to not show them to you ever.) (Perhaps another application of this functionality would be to “mute” certain threads on a mailing list. Then you could use a query for “word-i-am-interested-in AND tag:muted” to find out if something interesting pops up in a muted thread. Then in the show view, you will want to unmute the other thread messages.) Perhaps this could be an application of dme’s header-line collapsing functionality in id:cun8vl5m610@hotblack-desiato.hh.sledj.net (suitably cleaned up), such that you see only a single line in the show buffer that says: - 6 messages hidden - instead of the 6 (or however many) individual messages. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Quote MML tags in replies
On Thu, 19 Jan 2012 17:46:31 -0500, Austin Clements amdra...@mit.edu wrote: ### OT: For some reason, `mml-quote-region' explicitly re-quotes already quoted MML tags: #!*/?\\(multipart\\|part\\|external\\|mml\\) Why is that ? Probably so the transformation is invertible, though as far as I can tell there's no mml-unquote-region. Sending the message (or doing M-x mml-preview) undoes the quoting. So if the original message contains an already-quoted tag, constructing the reply double-quotes it, and sending the reply will produce the original single-quoted tag again. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Quote MML tags in replies
On Thu, 19 Jan 2012 17:48:42 -0500, Austin Clements amdra...@mit.edu wrote: Did you consider using point-max instead of mark? IIRC, that mark was very recently introduced which, perhaps irrationally, makes it seem less future-proof to me. Well, if the patch goes in and someone changes the code so that it no longer sets the mark (in the same way), they will be the one breaking stuff, and they’ll have to come up with the fix themself. Using point-max would include the signature in the quoting as well. It would probably be fairly odd to want to put an MML tag in one’s signature, but that doesn’t mean that we should break that usage. (defun notmuch-mua-forward-message () (message-forward) Speaking of future-proofing, it would be good to have a test. It would. ;) I’ll work on one. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Quote MML tags in replies
On Fri, 20 Jan 2012 00:21:08 +0100, Pieter Praet pie...@praet.org wrote: So, would I be right to assume MML tags in signatures are never evaluated to begin with? Otherwise, there would still be a security hole, no? I am thinking of MML tags that a user puts in their own signature. If that case is a security hole, then the hole is in the user’s brain and not in notmuch. :) -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply
On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: On Thu, Jan 19, 2012 at 11:45, Aaron Ecay e...@sas.upenn.edu wrote: Shouldn’t this just use message-insert-formatted-citation-line? Yes, good idea. I just tried this and it almost works. The only issue is that the default message-mode-citation-line-format has a newline at the end, and this function inserts an *additional* newline, so we end up with a blank line before the beginning of the quoted text. This is fixable by the user, of course, but it means the default out-of-the-box setup will create funny-looking replies, which is probably bad. Thoughts? (let ((message-citation-line-format (remove ?\n message-citation-line-format))) ...) (Or, if you think someone might have a newline other than at the end of the string, you could do something a little more complicated to remove only a newline at the end.) Or you could introduce a new defcustom ‘notmuch-message-citation-line-format’ (with newline-less default), and let-bind m-l-c-f to that value. But that is pretty ugly – we don’t want to have to “wrap” every variable whose default we don’t like. I've also tried using message-cite-original to create the reply body, and it also almost works. The issue, again, is one of defaults. In addition to the blank line I mentioned above, the default message-citation-line-function inserts the plain citation line Foo f...@bar.baz writes: instead of the formatted one. This is a big change from the current notmuch default. If everyone's OK with this and willing to customize it themselves, then I'm happy to go with this solution, but I'm pretty reluctant to change the default in such a significant way. I’m personally of the opinion that notmuch should just say “the mail composition facility is provided by message mode (here is the documentation on customizing it)”. Message mode is 8,000 lines of elisp. We have the choice to: - write our own message composition mode - wrap (as explained above) the default message-mode variables we don’t like in notmuch-prefixed variants, with suitable let-bindings. - use only the parts of message-mode that we like - pass composition off to message mode The first option just doesn’t make sense. The second is also a little nuts. The third is what we are trying now, but it’s painful – the message mode code has its own structure and its own defaults, which don’t always agree with notmuch’s. I am in favor of the fourth – notmuch’s elisp code should pass data to message mode in the most low level form it can, and let message mode do any extra work in the way it already does. And users should customize message composition via message mode, not notmuch. There’s a tradeoff to this approach – by controlling more within notmuch, we can have nicer defaults at the expense of more brittle code and/or fewer user-visible customizations. This is not in any way a criticism of your work (which is great) – you’re right that you need “permission” to uproot the defaults, and I’m advocating for it to be given. One possible step that might ease the transition pain could be for notmuch’s emacs interface to have a configuration file (similar to Wanderlust’s ~/.wl; I believe Gnus also uses a ~/.gnus). The idea is that this file contains elisp code, and is loaded by notmuch the first time any notmuch-related commands are invoked by the user. If the file does not exist, notmuch could create it with default content that sets message-citation-function, message-citation-line-format, message-yank-prefix (to get rid of the ugly default whereby message-mode indents the original message by four spaces instead of inserting “ ”), etc. If there is interest in this approach, I’d be happy to work on a patch for it. I’ve sort of stumped for this idea before (id:m239bgcd1d@gmail.com) and it didn’t exactly get rave reviews. So I’ll shut up if it’s really not something people want to see. I’ll close with an example of a nice feature that message mode has (which I’ve been really wanting since the reply keybindings changed) that notmuch would get for free if it hooked into message mode better: the function message-widen-reply takes a reply-to-sender message and makes it reply-to-all. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tach.el: an attachment interface for message mode.
Ha! As I was recently looking at the MML stuff, I spent some time googling around looking for this – I knew I had seen a “mutt-like” attachment interface for emacs mail writing, but I couldn’t seem to come across it. I will definitely get it set up and play with it. I don’t have cause to attach files to email very often, but I’ll let you know how it works out. Thanks a lot, -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: Add tests for quoting of MML tags in replies
The test is broken at this time; the next commit will introduce a fix. --- Thanks for the reminder, Austin. Things got hectic, and it took a little bludgeoning to get the test suite to behave. I *think* I got it, although I am by no means confident. Specifically, I am seeing some unrelated(?) test failures in the emacs suite, so I'd appreciate it if someone with a well-functioning test suite tried out these patches before they are pushed, to be sure I didn't break anything. I tried to follow the first patch introduces a failing test, second patch fixes it convention. test/emacs | 14 ++ test/emacs.expected-output/quote-mml |9 + 2 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 test/emacs.expected-output/quote-mml diff --git a/test/emacs b/test/emacs index 8ca4c8a..a57513a 100755 --- a/test/emacs +++ b/test/emacs @@ -273,6 +273,20 @@ On 01 Jan 2000 12:00:00 -, Notmuch Test Suite test_su...@notmuchmail.org w EOF test_expect_equal_file OUTPUT EXPECTED +test_begin_subtest Quote MML tags on reply +test_subtest_known_broken +add_message '[from]=1337 h4xor t...@test.com' \ +'[to]=Unsuspecting rube lu...@securityhole.com' \ +'[subject]=hackety hack hack' \ +'[body]=#part type=application/octet-stream filename=foo disposition=attachment +#/part' \ +'[id]=test-mml-quot...@msg.id' +test_emacs (notmuch-show \id:test-mml-quot...@msg.id\) +(notmuch-show-reply-sender) +(test-output) +test_expect_equal_file OUTPUT $EXPECTED/quote-mml + + test_begin_subtest Save attachment from within emacs using notmuch-show-save-attachments # save as archive to test that Emacs does not re-compress .gz test_emacs '(let ((standard-input \attachment1.gz\)) diff --git a/test/emacs.expected-output/quote-mml b/test/emacs.expected-output/quote-mml new file mode 100644 index 000..01bd2ca --- /dev/null +++ b/test/emacs.expected-output/quote-mml @@ -0,0 +1,9 @@ +From: Notmuch Test Suite test_su...@notmuchmail.org +To: 1337 h4xor t...@test.com +Subject: Re: hackety hack hack +In-Reply-To: test-mml-quot...@msg.id +Fcc: /home/aecay/development/notmuch/test/tmp.emacs/mail/sent +--text follows this line-- +On Fri, 05 Jan 2001 15:43:57 +, 1337 h4xor t...@test.com wrote: + #!part type=application/octet-stream filename=foo disposition=attachment + #!/part -- 1.7.9 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: Quote MML tags in replies
Emacs message-mode uses certain text strings to indicate how to attach files to outgoing mail. If these are present in the text of an email, and a user is tricked into replying to the message, the user’s files could be exposed. --- NEWS | 18 ++ emacs/notmuch-mua.el |3 ++- test/emacs |1 - 3 files changed, 20 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 2acdce5..c8b90c7 100644 --- a/NEWS +++ b/NEWS @@ -56,6 +56,24 @@ Compatibility with GMime 2.6 However, a bug in current GMime 2.6 causes notmuch not to report signatures where the signer key is unavailable (GNOME bug 668085). +Notmuch 0.11.1 (2012-xx-xx) +=== + +Emacs Interface +--- + +Quote MML tags in replies + + MML tags are text codes that Emacs uses to indicate attachments + (among other things) in messages being composed. The Emacs + interface did not quote MML tags in the quoted text of a reply. If + a user could be tricked into replying to a maliciously formatted + message and not editing out the MML tags from the quoted text, this + could lead to files from the user's machine being attached to the + outgoing message. The Emacs interface now quotes these tags in + reply text, so that they cannot have an effect on the outgoing + message. + Notmuch 0.11 (2012-01-13) = diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 023645e..32c376d 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -116,7 +116,8 @@ list. (push-mark)) (set-buffer-modified-p nil) - (message-goto-body)) + (message-goto-body) + (mml-quote-region (point) (mark))) (defun notmuch-mua-forward-message () (message-forward) diff --git a/test/emacs b/test/emacs index a57513a..affcca4 100755 --- a/test/emacs +++ b/test/emacs @@ -274,7 +274,6 @@ EOF test_expect_equal_file OUTPUT EXPECTED test_begin_subtest Quote MML tags on reply -test_subtest_known_broken add_message '[from]=1337 h4xor t...@test.com' \ '[to]=Unsuspecting rube lu...@securityhole.com' \ '[subject]=hackety hack hack' \ -- 1.7.9 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug related to ical
The problem is in the ‘notmuch-show-insert-part-text/calendar’ function. The call to ‘icalendar--convert-ical-to-diary’ does not create a buffer visiting the temp file, so the call to ‘set-buffer’ fails. The following patch fixes the problem. The ical-diary conversion also doesn’t seem to work – the calendar attachment shows up as an empty part – but I guess that’s a separate issue (and not addressed by the patch). I guess that part insertion handlers should be called inside a ‘condition-case’, so that an error inside of one can be recovered from, and doesn’t entirely derail the insertion of the messages in the buffer. (I actually made this patch because I was so annoyed that Olivier’s buggy test attachment made it impossible for me to read Tomi’s reply.) - cut here - diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el index ce5ea6f..4c89d7e 100644 --- i/emacs/notmuch-show.el +++ w/emacs/notmuch-show.el @@ -746,7 +746,7 @@ message at DEPTH in the current thread. (icalendar--convert-ical-to-diary (icalendar--read-element nil nil) file t) - (set-buffer (get-file-buffer file)) + (set-buffer (find-file-noselect file)) (setq result (buffer-substring (point-min) (point-max))) (set-buffer-modified-p nil) (kill-buffer (current-buffer)) - cut here - -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: display tags in notmuch-show with links
2012ko azaroak 18an, Ethan Glasser-Camp-ek idatzi zuen: - You might want to use #' on lambdas. This is actually unnecessary – as the info node (elisp) Anonymous Functions says, the forms with and without #' are equivalent. The current notmuch style is not to have #' on lambdas (that is, there are 0 instances of #'(lambda ...) in the code base). IMO that’s correct: the unnecessary #' is just line-noise-ish. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] [PATCH] lib/database.cc: change how the parent of a message is calculated
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To header, such as the email address of the sender of the
parent. This can fool notmuch.
The updated algorithm prefers the last Message ID in the References
header. The References header lists messages oldest-first, so the last
Message ID is the parent (RFC2822, p. 24). The References header is
also less likely to be in a non-standard
syntax (http://cr.yp.to/immhf/thread.html,
http://www.jwz.org/doc/threading.html). In case the References header
is not to be found, fall back to the old behavior.
---
I especially notice this problem on public mailing lists, where
certain people's messages always cause an out-dent of the threading,
instead of being nested under whichever message they are replies to.
Technically, putting non-Message-ID crud in the In-Reply-To field is a
violation of RFC2822, but it appears that in practice the References
header is respected more often than the In-Reply-To one.
lib/database.cc | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 91d4329..cbf33ae 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -501,8 +501,10 @@ _parse_message_id (void *ctx, const char *message_id,
const char **next)
* 'message_id' in the result (to avoid mass confusion when a single
* message references itself cyclically---and yes, mail messages are
* not infrequent in the wild that do this---don't ask me why).
+ *
+ * Return the last reference parsed.
*/
-static void
+static char *
parse_references (void *ctx,
const char *message_id,
GHashTable *hash,
@@ -511,7 +513,7 @@ parse_references (void *ctx,
char *ref;
if (refs == NULL || *refs == '\0')
- return;
+ return NULL;
while (*refs) {
ref = _parse_message_id (ctx, refs, refs);
@@ -519,6 +521,8 @@ parse_references (void *ctx,
if (ref strcmp (ref, message_id))
g_hash_table_insert (hash, ref, NULL);
}
+
+return ref;
}
notmuch_status_t
@@ -1365,7 +1369,7 @@ _notmuch_database_generate_doc_id (notmuch_database_t
*notmuch)
notmuch-last_doc_id++;
if (notmuch-last_doc_id == 0)
- INTERNAL_ERROR (Xapian document IDs are exhausted.\n);
+ INTERNAL_ERROR (Xapian document IDs are exhausted.\n);
return notmuch-last_doc_id;
}
@@ -1509,7 +1513,7 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
const char **thread_id)
{
GHashTable *parents = NULL;
-const char *refs, *in_reply_to, *in_reply_to_message_id;
+const char *refs, *in_reply_to, *in_reply_to_message_id,
*last_ref_message_id;
GList *l, *keys = NULL;
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
@@ -1517,21 +1521,31 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
_my_talloc_free_for_g_hash, NULL);
refs = notmuch_message_file_get_header (message_file, references);
-parse_references (message, notmuch_message_get_message_id (message),
- parents, refs);
+last_ref_message_id = parse_references (message,
+ notmuch_message_get_message_id
(message),
+ parents, refs);
in_reply_to = notmuch_message_file_get_header (message_file,
in-reply-to);
parse_references (message, notmuch_message_get_message_id (message),
parents, in_reply_to);
-/* Carefully avoid adding any self-referential in-reply-to term. */
in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);
+/* If the parent message ID from the Reply-To and References
+ * headers are different, use the References one. This is because
+ * the Reply-To header is more likely to be in an non-standard
+ * format. */
+if (in_reply_to_message_id
+ last_ref_message_id
+ strcmp (last_ref_message_id, in_reply_to_message_id)) {
+ in_reply_to_message_id = last_ref_message_id;
+}
+/* Carefully avoid adding any self-referential in-reply-to term. */
if (in_reply_to_message_id
strcmp (in_reply_to_message_id,
notmuch_message_get_message_id (message)))
{
_notmuch_message_add_term (message, replyto,
-_parse_message_id (message, in_reply_to, NULL));
+in_reply_to_message_id);
}
keys = g_hash_table_get_keys (parents);
--
1.8.1.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] test: add tests for the handling of References and In-Reply-To headers
These tests are known_broken, the following commit fixes them.
---
Thanks to David and Tomi for pointing out test_expect_equal_json. In
the process of implementing that, I discovered
notmuch_json_show_sanitize, which I had also not been using. This
patch fixes the test to use both these conveniences. The second patch
is not changed substantively, but I am resending it for tidiness.
test/thread-replies | 144
1 file changed, 144 insertions(+)
create mode 100755 test/thread-replies
diff --git a/test/thread-replies b/test/thread-replies
new file mode 100755
index 000..a902691
--- /dev/null
+++ b/test/thread-replies
@@ -0,0 +1,144 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2013 Aaron Ecay
+#
+
+test_description='test of proper handling of in-reply-to and references headers
+
+This test makes sure that the thread structure in the notmuch database is
+constructed properly, even in the presence of non-RFC-compliant headers'
+
+. ./test-lib.sh
+
+test_begin_subtest Use References when In-Reply-To is broken
+test_subtest_known_broken
+add_message '[id]=f...@one.com' \
+'[subject]=one'
+add_message '[in-reply-to]=mumble' \
+'[references]=f...@one.com' \
+'[subject]=Re: one'
+output=$(notmuch show --format=json 'subject:one' | notmuch_json_show_sanitize)
+expected='[[[{id: f...@one.com,
+ match: true,
+ excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-001,
+ timestamp: 978709437,
+ date_relative: 2001-01-05,
+ tags: [inbox, unread],
+ headers: {Subject: one,
+ From: Notmuch Test Suite test_su...@notmuchmail.org,
+ To: Notmuch Test Suite test_su...@notmuchmail.org,
+ Date: Fri, 05 Jan 2001 15:43:57 +},
+ body: [{id: 1,
+ content-type: text/plain,
+ content: This is just a test message (#1)\n}]},
+ [[{id: msg-002@notmuch-test-suite,
+ match: true, excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-002,
+ timestamp: 978709437, date_relative: 2001-01-05,
+ tags: [inbox, unread], headers: {Subject: Re: one,
+ From: Notmuch Test Suite test_su...@notmuchmail.org,
+ To: Notmuch Test Suite test_su...@notmuchmail.org,
+ Date: Fri, 05 Jan 2001 15:43:57 +},
+ body: [{id: 1, content-type: text/plain,
+ content: This is just a test message (#2)\n}]}, []]'
+expected=`echo $expected | notmuch_json_show_sanitize`
+test_expect_equal_json $output $expected
+
+test_begin_subtest Prefer References to In-Reply-To
+test_subtest_known_broken
+add_message '[id]=f...@two.com' \
+'[subject]=two'
+add_message '[in-reply-to]=b...@baz.com' \
+'[references]=f...@two.com' \
+'[subject]=Re: two'
+output=$(notmuch show --format=json 'subject:two' | notmuch_json_show_sanitize)
+expected='[[[{id: f...@two.com,
+ match: true, excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-003,
+ timestamp: 978709437, date_relative: 2001-01-05, tags: [inbox,
unread],
+ headers: {Subject: two,
+ From: Notmuch Test Suite test_su...@notmuchmail.org,
+ To: Notmuch Test Suite test_su...@notmuchmail.org,
+ Date: Fri, 05 Jan 2001 15:43:57 +},
+ body: [{id: 1, content-type: text/plain,
+ content: This is just a test message (#3)\n}]},
+ [[{id: msg-004@notmuch-test-suite, match: true, excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-004,
+ timestamp: 978709437, date_relative: 2001-01-05, tags: [inbox,
unread],
+ headers: {Subject: Re: two,
+ From: Notmuch Test Suite test_su...@notmuchmail.org,
+ To: Notmuch Test Suite test_su...@notmuchmail.org,
+ Date: Fri, 05 Jan 2001 15:43:57 +},
+ body: [{id: 1,
+ content-type: text/plain, content: This is just a test message
(#4)\n}]},
+ []]'
+expected=`echo $expected | notmuch_json_show_sanitize`
+test_expect_equal_json $output $expected
+
+test_begin_subtest Use In-Reply-To when no References
+test_subtest_known_broken
+add_message '[id]=f...@three.com' \
+'[subject]=three'
+add_message '[in-reply-to]=f...@three.com' \
+'[subject]=Re: three'
+output=$(notmuch show --format=json 'subject:three' |
notmuch_json_show_sanitize)
+expected='[[[{id: f...@three.com, match: true, excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-005,
+ timestamp: 978709437, date_relative: 2001-01-05, tags: [inbox,
unread],
+ headers: {Subject: three,
+ From: Notmuch Test Suite test_su...@notmuchmail.org,
+ To: Notmuch Test Suite test_su...@notmuchmail.org,
+ Date: Fri, 05 Jan 2001 15:43:57 +}, body: [{id: 1,
+ content-type: text/plain, content: This is just a test message
(#5)\n}]},
+ [[{id: msg-006@notmuch-test-suite, match: true, excluded: false,
+ filename:
/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-006,
+ timestamp: 978709437, date_relative
[PATCH 2/2] lib/database.cc: change how the parent of a message is calculated
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To header, such as the email address of the sender of the
parent. This can fool notmuch.
The updated algorithm prefers the last Message ID in the References
header. The References header lists messages oldest-first, so the last
Message ID is the parent (RFC2822, p. 24). The References header is
also less likely to be in a non-standard
syntax (http://cr.yp.to/immhf/thread.html,
http://www.jwz.org/doc/threading.html). In case the References header
is not to be found, fall back to the old behavior.
V2 of this patch, incorporating feedback from Jani and (indirectly)
Austin.
---
lib/database.cc | 48 +---
test/thread-replies | 4
2 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 91d4329..52ed618 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -501,8 +501,10 @@ _parse_message_id (void *ctx, const char *message_id,
const char **next)
* 'message_id' in the result (to avoid mass confusion when a single
* message references itself cyclically---and yes, mail messages are
* not infrequent in the wild that do this---don't ask me why).
-*/
-static void
+ *
+ * Return the last reference parsed, if it is not equal to message_id.
+ */
+static char *
parse_references (void *ctx,
const char *message_id,
GHashTable *hash,
@@ -511,7 +513,7 @@ parse_references (void *ctx,
char *ref;
if (refs == NULL || *refs == '\0')
- return;
+ return NULL;
while (*refs) {
ref = _parse_message_id (ctx, refs, refs);
@@ -519,6 +521,17 @@ parse_references (void *ctx,
if (ref strcmp (ref, message_id))
g_hash_table_insert (hash, ref, NULL);
}
+
+/* The return value of this function is used to add a parent
+ * reference to the database. We should avoid making a message
+ * its own parent, thus the following check.
+ */
+
+if (ref strcmp(ref, message_id)) {
+ return ref;
+} else {
+ return NULL;
+}
}
notmuch_status_t
@@ -1510,28 +1523,33 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
{
GHashTable *parents = NULL;
const char *refs, *in_reply_to, *in_reply_to_message_id;
+const char *last_ref_message_id, *this_message_id;
GList *l, *keys = NULL;
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
parents = g_hash_table_new_full (g_str_hash, g_str_equal,
_my_talloc_free_for_g_hash, NULL);
+this_message_id = notmuch_message_get_message_id (message);
refs = notmuch_message_file_get_header (message_file, references);
-parse_references (message, notmuch_message_get_message_id (message),
- parents, refs);
+last_ref_message_id = parse_references (message,
+ this_message_id,
+ parents, refs);
in_reply_to = notmuch_message_file_get_header (message_file,
in-reply-to);
-parse_references (message, notmuch_message_get_message_id (message),
- parents, in_reply_to);
-
-/* Carefully avoid adding any self-referential in-reply-to term. */
-in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);
-if (in_reply_to_message_id
- strcmp (in_reply_to_message_id,
- notmuch_message_get_message_id (message)))
-{
+in_reply_to_message_id = parse_references (message,
+ this_message_id,
+ parents, in_reply_to);
+
+/* For the parent of this message, use the last message ID of the
+ * References header, if available. If not, fall back to the
+ * first message ID in the In-Reply-To header. */
+if (last_ref_message_id) {
+_notmuch_message_add_term (message, replyto,
+ last_ref_message_id);
+} else if (in_reply_to_message_id) {
_notmuch_message_add_term (message, replyto,
-_parse_message_id (message, in_reply_to, NULL));
+in_reply_to_message_id);
}
keys = g_hash_table_get_keys (parents);
diff --git a/test/thread-replies b/test/thread-replies
index a902691..28c2b1f 100755
--- a/test/thread-replies
+++ b/test/thread-replies
@@ -11,7 +11,6 @@ constructed properly, even in the presence of
non-RFC-compliant headers'
. ./test-lib.sh
test_begin_subtest Use References when In-Reply-To is broken
-test_subtest_known_broken
add_message '[id]=f...@one.com' \
'[subject]=one'
add_message '[in-reply-to]=mumble'
Re: [PATCH v2] emacs: Add support for saved search accelerators
Hello, 2014ko maiatzak 8an, Mark Walters-ek idatzi zuen: Hi This version looks good to me. The only slight query I have is which key to bind it to: Austin used g in notmuch-go and this uses j. Austin said on irc that he chose g because it wasn't bound and matched gmail's shortcut. Personally I like j (as it starts fewer words than g) and given that we don't match any of gmail's other bindings I don't think there is much advantage to doing so in this case. All other things being equal, I’d prefer “j” here, but for different reasons. “g” is the emacs-standard key to refresh or revert a buffer. In my personal customization file I bound “g” to notmuch-refresh-this-buffer in notmuch-(show/search)-mode-map long ago (and forgot this binding was not standard until reading above that g is not bound). It’s probably better emacs citizenship to not use such a standard key for a different purpose. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp completion patches v6
Hi David, 2015ko urriak 24an, David Bremner-ek idatzi zuen: > > Main changes since v5: > >- replace use of notmuch-message-message-insinuate. I'm not sure if > we should leave a stub function, or just break people's .emacs, > and tell them not to call it anymore. Maybe you could use a combination of ‘make-obsolete’ (for byte-compiler warnings) and ‘display-warning’ (for runtime)? I understand the desire to phase the function out eventually rather than have an eternal stub, but intentionally breaking .emacs is a really drastic step. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: elisp + company completion patches, v7
2015ko urriak 25an, David Bremner-ek idatzi zuen: > > This round contains several bug fixes from Mark, and a slightly > re-organized initialization from me. In particular, TAB should now > behave sanely under company. Also there's a stub > notmuch-address-message-insinuate to prevent peoples emacs startup > from failing. Guess who wrote a reply before catching up on all the list mail. :P -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v1] emacs: Allow part preferences to depend on message content.
Hi David, 2016ko urtarrilak 15an, David Edmondson-ek idatzi zuen: > > Currently the preference for which sub-part of a multipart/alternative > part is shown is global. Allow to the user to override the settings on a > per-message basis by providing two new options: > > - the ability to call a function that has access to the message to > return the discouraged type list, > - a simple evaluation environment to reduce the need for most users to > write their own function. > > The original approach is retained as the default. > --- > emacs/notmuch-lib.el | 39 +++ > emacs/notmuch-mua.el | 2 +- > emacs/notmuch-show.el | 2 +- > 3 files changed, 37 insertions(+), 6 deletions(-) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 89c01a5..2b9d108 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -520,11 +520,42 @@ This replaces spaces, percents, and double quotes in > STR with > "multipart/related" > )) > > -(defun notmuch-multipart/alternative-choose (types) > - "Return a list of preferred types from the given list of types" > +(defun notmuch-multipart/alternative-determine-discouraged-1 (msg directive) > + (let* ((headers (plist-get msg :headers)) > + ;; Headers that we make available: > + (from (plist-get headers :From)) > + (subject (plist-get headers :Subject)) > + (to (plist-get headers :To)) > + (cc (plist-get headers :Cc))) > + > +(eval directive))) This code is not compatible with lexical binding in emacs >= 24, which I assume notmuch will eventually want to adopt. What’s so bad about writing a function? -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch's search view sucks
--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen: [...] > TextCat is in Perl. I don't know if there's a C or C++ implementation but > it isn't a huge piece of code - finding a good technique was the clever part > of it. The same algorithm is implemented in C here: http://www.mnogosearch.org/guesser/ Licensed under the GPL and includes presets for ~50 languages. A potential drawback is that it doesn't handle raw HTML very well, according to the documentation. Aaron
[notmuch] [PATCH] Further improvements to tag-based coloring in search.
Makes the following improvements:
- fix up doc strings
- suppress the creation of unnecessary let-bindings
- create overlays lazily (to avoid creating many overlays for threads
that do not get colored)
Signed-off-by: Aaron Ecay
---
notmuch.el | 29 ++---
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 46159af..fff2192 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1257,8 +1257,7 @@ This function advances the next thread when finished."
'(("delete" . (:foreground "DarkGrey")))
"Tag/face mapping for line highlighting in notmuch-search.
-Here is an example of how to color search results based on tags.
-(the following text would be placed in your ~/.emacs file):
+Here is an example of how to color search results based on tags:
(setq notmuch-search-line-faces '((\"delete\" . (:foreground \"red\"))
(\"unread\" . (:foreground \"green\"
@@ -1269,19 +1268,19 @@ matching will be applied."
:group 'notmuch)
(defun notmuch-search-color-line (start end line-tag-list)
- "Colorize lines in notmuch-search based on tags"
- (if notmuch-search-line-faces
- (let ((overlay (make-overlay start end))
- (tags-faces (copy-alist notmuch-search-line-faces)))
- (while tags-faces
- (let* ((tag-face (car tags-faces))
-(tag (car tag-face))
-(face (cdr tag-face)))
- (cond ((member tag line-tag-list)
- (overlay-put overlay 'face face)
- (setq tags-faces nil))
- (t
- (setq tags-faces (cdr tags-faces)
+ "Colorize lines in notmuch-search based on tags.
+
+Uses the tag/face mappings found in `notmuch-search-line-faces'."
+ (when notmuch-search-line-faces
+(let ((tags-faces notmuch-search-line-faces))
+ (while tags-faces
+(let ((tag (caar tags-faces))
+ (face (cdar tags-faces)))
+ (cond ((member tag line-tag-list)
+ (overlay-put (make-overlay start end) 'face face)
+ (setq tags-faces nil))
+(t
+ (setq tags-faces (cdr tags-faces)
(defun notmuch-search-process-filter (proc string)
"Process and filter the output of \"notmuch search\""
--
1.6.6
[notmuch] [PATCH] notmuch.el: colorize lines in notmuch-search based on thread tags.
--- 2010ko Otsailak 7an, "Aneesh Kumar K. V"-ek idatzi zuen: > Doesn't 92c4dcc641e9dfb5f65026ebae5cedc8eb1d9e21 help you achive something > similar ? That commit allows colors to be applied to the tag name only, whereas this patch applies the color to the whole line. Which method(s) notmuch should support is debatable, of course. Mutt does whole-line coloring, FWIW. I should also point out that tag-based coloring is problematic in the current emacs interface, wherein long subjects can push the tags off the right side of the window. That is arguably a bug, but until it is fixed the utility of tag-only coloring is limited. Aaron
[PATCH] Further improvements to tag-based coloring in search.
Makes the following improvements: - fix up doc strings - suppress the creation of unnecessary let-bindings - create overlays lazily (to avoid creating many overlays for threads that do not get colored) Signed-off-by: Aaron Ecay --- emacs/notmuch.el | 21 ++--- 1 files changed, 10 insertions(+), 11 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..03d89c1 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -605,8 +605,7 @@ This function advances the next thread when finished." (defcustom notmuch-search-line-faces nil "Tag/face mapping for line highlighting in notmuch-search. -Here is an example of how to color search results based on tags. -(the following text would be placed in your ~/.emacs file): +Here is an example of how to color search results based on tags: (setq notmuch-search-line-faces '((\"delete\" . '(:foreground \"red\")) (\"unread\" . '(:foreground \"green\" @@ -617,16 +616,16 @@ matching will be applied." :group 'notmuch) (defun notmuch-search-color-line (start end line-tag-list) - "Colorize lines in notmuch-show based on tags" - (if notmuch-search-line-faces - (let ((overlay (make-overlay start end)) - (tags-faces (copy-alist notmuch-search-line-faces))) - (while tags-faces - (let* ((tag-face (car tags-faces)) -(tag (car tag-face)) -(face (cdr tag-face))) + "Colorize lines in notmuch-show based on tags. + +Uses the tag/face mappings found in `notmuch-search-line-faces'." + (when notmuch-search-line-faces +(let ((tags-faces notmuch-search-line-faces)) + (while tags-faces +(let ((tag (caar tags-faces)) + (face (cdar tags-faces))) (cond ((member tag line-tag-list) - (overlay-put overlay 'face face) + (overlay-put (make-overlay start end) 'face face) (setq tags-faces nil)) (t (setq tags-faces (cdr tags-faces) -- 1.7.0.4
Build problems on OS X
In the process of updating to the latest sources, I've discovered that notmuch no longer builds on OS X. As a reply to this email, I'll be sending 4 patches. The first two are bugfixes; the third adds the infrastructure to the Makefiles to build a shared library on OS X, since the Mach-O conventions are somewhat different than the Linux ones. Modulo makefile style quibbles, this patch should be correct. The fourth patch I am not sure of. Even after adding the proper command line flags to build the shared binary on OS X, I get symbol not found errors for Glib/Gmime symbols. The shared binary links against the shared lib, which in turn links against Glib and Gmime, but it appears that at least on OS X the linker won't follow these second-order links, and the notmuch shared binary must be linked against Glib/Gmime directly. This patch fixes the build for me, but it may not be correct on Linux/other Unices. I can resubmit this patch to add the extra linker flags only when building for OS X. If anyone knows how to get the OS X linker to behave like the Linux one in this regard, that will likely be a better solution. Aaron
[PATCH 1/4] Use C++ compiler to link notmuch binaries
Since the binaries contain C++ code, it is necessary to use the C++ linker, or errors result on some platforms (OS X). Signed-off-by: Aaron Ecay --- Makefile.local |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.local b/Makefile.local index 71525e2..9e753cd 100644 --- a/Makefile.local +++ b/Makefile.local @@ -216,10 +216,10 @@ notmuch_client_srcs = \ notmuch_client_modules = $(notmuch_client_srcs:.c=.o) notmuch: $(notmuch_client_modules) lib/libnotmuch.a - $(call quiet,CC $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@ + $(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@ notmuch-shared: $(notmuch_client_modules) lib/libnotmuch.so - $(call quiet,CC $(CFLAGS)) $(notmuch_client_modules) $(FINAL_NOTMUCH_LDFLAGS) -o $@ + $(call quiet,CXX $(CFLAGS)) $(notmuch_client_modules) $(FINAL_NOTMUCH_LDFLAGS) -o $@ notmuch.1.gz: notmuch.1 gzip --stdout $^ > $@ -- 1.7.0.4
[PATCH 2/4] Fix up Makefile for build.
Must set extra_c(xx)flags before including subdir Makefile.local's, so that there is a blank slate that the subdirs can add on to. Must include subdir Makefile.local's before global one, otherwise the compat sources are not added to the list of those to be compiled. Signed-off-by: Aaron Ecay --- Makefile |9 - Makefile.local|5 - compat/Makefile.local |2 +- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 076efc7..faaaec6 100644 --- a/Makefile +++ b/Makefile @@ -9,6 +9,13 @@ subdirs = compat completion emacs lib global_deps = Makefile Makefile.local \ $(subdirs:%=%/Makefile) $(subdirs:%=%/Makefile.local) +# Sub-directory Makefile.local fragments can append to these variables +# to have directory-specific cflags as necessary. + +extra_cflags := +extra_cxxflags := + # Finally, include all of the Makefile.local fragments where all the # real work is done. -include Makefile.local $(subdirs:%=%/Makefile.local) + +include $(subdirs:%=%/Makefile.local) Makefile.local diff --git a/Makefile.local b/Makefile.local index 9e753cd..c04044c 100644 --- a/Makefile.local +++ b/Makefile.local @@ -33,11 +33,6 @@ Makefile.config: configure @echo "" ./configure -# Sub-directory Makefile.local fragments can append to these variables -# to have directory-specific cflags as necessary. -extra_cflags := -extra_cxxflags := - # Smash together user's values with our extra values FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) diff --git a/compat/Makefile.local b/compat/Makefile.local index 81e6c70..50f6cd1 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -3,7 +3,7 @@ dir := compat extra_cflags += -I$(dir) -notmuch_compat_srcs = +notmuch_compat_srcs := ifneq ($(HAVE_GETLINE),1) notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c -- 1.7.0.4
[PATCH 3/4] Add infrastructure for building shared library on OS X.
This patch adds a configure check for OS X (actually Darwin), and sets up the Makefiles to build a proper shared library on that platform. Signed-off-by: Aaron Ecay --- Makefile |2 +- Makefile.local |2 +- configure | 13 + lib/Makefile.local | 16 ++-- 4 files changed, 29 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index faaaec6..86e08fa 100644 --- a/Makefile +++ b/Makefile @@ -18,4 +18,4 @@ extra_cxxflags := # Finally, include all of the Makefile.local fragments where all the # real work is done. -include $(subdirs:%=%/Makefile.local) Makefile.local +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local diff --git a/Makefile.local b/Makefile.local index c04044c..99d5b64 100644 --- a/Makefile.local +++ b/Makefile.local @@ -213,7 +213,7 @@ notmuch_client_modules = $(notmuch_client_srcs:.c=.o) notmuch: $(notmuch_client_modules) lib/libnotmuch.a $(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@ -notmuch-shared: $(notmuch_client_modules) lib/libnotmuch.so +notmuch-shared: $(notmuch_client_modules) lib/$(LINKER_NAME) $(call quiet,CXX $(CFLAGS)) $(notmuch_client_modules) $(FINAL_NOTMUCH_LDFLAGS) -o $@ notmuch.1.gz: notmuch.1 diff --git a/configure b/configure index 5af7852..da45572 100755 --- a/configure +++ b/configure @@ -234,6 +234,15 @@ else have_emacs=0 fi +printf "Checking for Mac OS X (for shared library)... " +if [ `uname` = "Darwin" ] ; then +printf "Yes.\n" +mac_os_x=1 +else +printf "No.\n" +mac_os_x=0 +fi + if [ $errors -gt 0 ]; then cat <
[PATCH 4/4] Add CONFIGURE_LDFLAGS to the notmuch-shared buld command line.
Otherwise, symbol not found errors result on OS X. I am not sure this is the correct solution for the problem, but it gets the build working. Signed-off-by: Aaron Ecay --- Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index 99d5b64..8d5fda4 100644 --- a/Makefile.local +++ b/Makefile.local @@ -36,7 +36,7 @@ Makefile.config: configure # Smash together user's values with our extra values FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(CONFIGURE_LDFLAGS) FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) .PHONY: all -- 1.7.0.4
Use of strcasestr
--- 2010ko Apirilak 12an, Tomas Carnecky-ek idatzi zuen: > > Adding that function to compat/ probably is the way to go, but the whole > compat mechanism doesn't work here. It's like if compat/Makefile.local was > not included in the top-level makefile, notmuch_compat_srcs is empty > there. Any ideas how to debug that? If you are referring to the bug I think you are, I sent a patch to the list to fix it yesterday. id:1271029494-89014-2-git-send-email-aaronecay at gmail.com Aaron
segfault: g_type_init() missing
Dear all, I just pulled the last couple weeks' worth of changes and rebuilt notmuch, only to have the new binary give a segfault on "notmuch new" (running on OS X.6). The error message printed was: (process:21821): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init() And the backtrace (from gdb): #0 0x000a18f7 in g_object_newv () #1 0x000160e4 in notmuch_filter_discard_uuencode_new () #2 0x000163f0 in _index_mime_part () #3 0x0001667a in _notmuch_message_index_file () #4 0x0001247c in notmuch_database_add_message () #5 0x65a9 in add_files_recursive () #6 0x612c in add_files_recursive () #7 0x612c in add_files_recursive () #8 0x71ec in notmuch_new_command () #9 0x3a5a in main () According to the Glib docs (http://developer.gnome.org/gobject/unstable/gobject-Type-Information.html#g-type-init), the g_type_init() function must be called before using any GType stuff, which notmuch_filter_discard_uuencode_new does. There are no grep hits for g_type_init in the notmuch sources, though. The code on the error path looks pretty old, so I'm not sure why this bug hasn't hit someone else before. Adding a call to g_type_init() to main() (right after g_mime_init(0)) fixes the problem. Aaron
[PATCH] Add missing call to g_type_init()
Signed-off-by: Aaron Ecay --- notmuch.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/notmuch.c b/notmuch.c index 3973e35..f9d6629 100644 --- a/notmuch.c +++ b/notmuch.c @@ -579,6 +579,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); g_mime_init (0); +g_type_init (); if (argc == 1) return notmuch (local); -- 1.7.6
[PATCH] Add missing call to g_type_init()
The Glib docs state "Prior to any use of the type system, g_type_init() has to be called".[1] To not do so can lead to segfaults. The g_type system is currently used by various "filters" that operate on uuencoded text, message headers, etc. [1] http://developer.gnome.org/gobject/2.28/gobject-Type-Information.html#g-type-init --- I have added a link to the Glib docs to the commit message, and a description of where the type code is used. There isn't an easy way to test for this bug, I think -- not including the init call is wrong by the API docs, but only sometimes yields a crash. notmuch.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/notmuch.c b/notmuch.c index 3973e35..f9d6629 100644 --- a/notmuch.c +++ b/notmuch.c @@ -579,6 +579,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); g_mime_init (0); +g_type_init (); if (argc == 1) return notmuch (local); -- 1.7.6
bug related to ical
The problem is in the ?notmuch-show-insert-part-text/calendar? function. The call to ?icalendar--convert-ical-to-diary? does not create a buffer visiting the temp file, so the call to ?set-buffer? fails. The following patch fixes the problem. The ical->diary conversion also doesn?t seem to work ? the calendar attachment shows up as an empty part ? but I guess that?s a separate issue (and not addressed by the patch). I guess that part insertion handlers should be called inside a ?condition-case?, so that an error inside of one can be recovered from, and doesn?t entirely derail the insertion of the messages in the buffer. (I actually made this patch because I was so annoyed that Olivier?s buggy test attachment made it impossible for me to read Tomi?s reply.) - cut here - diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el index ce5ea6f..4c89d7e 100644 --- i/emacs/notmuch-show.el +++ w/emacs/notmuch-show.el @@ -746,7 +746,7 @@ message at DEPTH in the current thread." (icalendar--convert-ical-to-diary (icalendar--read-element nil nil) file t) - (set-buffer (get-file-buffer file)) + (set-buffer (find-file-noselect file)) (setq result (buffer-substring (point-min) (point-max))) (set-buffer-modified-p nil) (kill-buffer (current-buffer)) - cut here ----- -- Aaron Ecay
[PATCH v2] emacs: display tags in notmuch-show with links
2012ko azaroak 18an, Ethan Glasser-Camp-ek idatzi zuen: > > - You might want to use #' on lambdas. This is actually unnecessary ? as the info node "(elisp) Anonymous Functions" says, the forms with and without #' are equivalent. The current notmuch style is not to have #' on lambdas (that is, there are 0 instances of #'(lambda ...) in the code base). IMO that?s correct: the unnecessary #' is just line-noise-ish. -- Aaron Ecay
[RFC] [PATCH] lib/database.cc: change how the parent of a message is calculated
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To header, such as the email address of the sender of the
parent. This can fool notmuch.
The updated algorithm prefers the last Message ID in the References
header. The References header lists messages oldest-first, so the last
Message ID is the parent (RFC2822, p. 24). The References header is
also less likely to be in a non-standard
syntax (http://cr.yp.to/immhf/thread.html,
http://www.jwz.org/doc/threading.html). In case the References header
is not to be found, fall back to the old behavior.
---
I especially notice this problem on public mailing lists, where
certain people's messages always cause an "out-dent" of the threading,
instead of being nested under whichever message they are replies to.
Technically, putting non-Message-ID crud in the In-Reply-To field is a
violation of RFC2822, but it appears that in practice the References
header is respected more often than the In-Reply-To one.
lib/database.cc | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 91d4329..cbf33ae 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -501,8 +501,10 @@ _parse_message_id (void *ctx, const char *message_id,
const char **next)
* 'message_id' in the result (to avoid mass confusion when a single
* message references itself cyclically---and yes, mail messages are
* not infrequent in the wild that do this---don't ask me why).
+ *
+ * Return the last reference parsed.
*/
-static void
+static char *
parse_references (void *ctx,
const char *message_id,
GHashTable *hash,
@@ -511,7 +513,7 @@ parse_references (void *ctx,
char *ref;
if (refs == NULL || *refs == '\0')
- return;
+ return NULL;
while (*refs) {
ref = _parse_message_id (ctx, refs, );
@@ -519,6 +521,8 @@ parse_references (void *ctx,
if (ref && strcmp (ref, message_id))
g_hash_table_insert (hash, ref, NULL);
}
+
+return ref;
}
notmuch_status_t
@@ -1365,7 +1369,7 @@ _notmuch_database_generate_doc_id (notmuch_database_t
*notmuch)
notmuch->last_doc_id++;
if (notmuch->last_doc_id == 0)
- INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");
+ INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");
return notmuch->last_doc_id;
}
@@ -1509,7 +1513,7 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
const char **thread_id)
{
GHashTable *parents = NULL;
-const char *refs, *in_reply_to, *in_reply_to_message_id;
+const char *refs, *in_reply_to, *in_reply_to_message_id,
*last_ref_message_id;
GList *l, *keys = NULL;
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
@@ -1517,21 +1521,31 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
_my_talloc_free_for_g_hash, NULL);
refs = notmuch_message_file_get_header (message_file, "references");
-parse_references (message, notmuch_message_get_message_id (message),
- parents, refs);
+last_ref_message_id = parse_references (message,
+ notmuch_message_get_message_id
(message),
+ parents, refs);
in_reply_to = notmuch_message_file_get_header (message_file,
"in-reply-to");
parse_references (message, notmuch_message_get_message_id (message),
parents, in_reply_to);
-/* Carefully avoid adding any self-referential in-reply-to term. */
in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);
+/* If the parent message ID from the Reply-To and References
+ * headers are different, use the References one. This is because
+ * the Reply-To header is more likely to be in an non-standard
+ * format. */
+if (in_reply_to_message_id &&
+ last_ref_message_id &&
+ strcmp (last_ref_message_id, in_reply_to_message_id)) {
+ in_reply_to_message_id = last_ref_message_id;
+}
+/* Carefully avoid adding any self-referential in-reply-to term. */
if (in_reply_to_message_id &&
strcmp (in_reply_to_message_id,
notmuch_message_get_message_id (message)))
{
_notmuch_message_add_term (message, "replyto",
-_parse_message_id (message, in_reply_to, NULL));
+in_reply_to_message_id);
}
keys = g_hash_table_get_keys (parents);
--
1.8.1.4
[RFC] [PATCH] lib/database.cc: change how the parent of a message is calculated
2013ko otsailak 26an, Jani Nikula-ek idatzi zuen: > Hi Aaron, please provide references to a few messages like this. If > available on the notmuch list an id: reference would be best, but > otherwise some archive that allows viewing full message headers or > downloading the full message would be best. Here?s a message from the notmuch list that has passed through gmane, which inserts References but not In-Reply-To headers: id:877h0sa207.fsf at fester.com . Here?s a link to one with a borked In-Reply-To header: http://article.gmane.org/gmane.emacs.orgmode/66616/raw -- Aaron Ecay
[RFC] [PATCH] lib/database.cc: change how the parent of a message is calculated
git send-email is mad about lines >998 characters in the test patch, so I?m sending the patches as attachments to this email. (Is there a better way to include the expected output of a notmuch command which outputs long lines in a test script?) -- next part -- A non-text attachment was scrubbed... Name: 0001-test-add-tests-for-the-handling-of-References-and-In.patch Type: text/x-patch Size: 7358 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130303/f34f47b6/attachment-0002.bin> -- next part -- A non-text attachment was scrubbed... Name: 0002-lib-database.cc-change-how-the-parent-of-a-message-i.patch Type: text/x-patch Size: 9138 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130303/f34f47b6/attachment-0003.bin> -- next part ------ -- Aaron Ecay
[PATCH 1/2] test: add tests for the handling of References and In-Reply-To headers
These tests are known_broken, the following commit fixes them.
---
Thanks to David and Tomi for pointing out test_expect_equal_json. In
the process of implementing that, I discovered
notmuch_json_show_sanitize, which I had also not been using. This
patch fixes the test to use both these conveniences. The second patch
is not changed substantively, but I am resending it for tidiness.
test/thread-replies | 144
1 file changed, 144 insertions(+)
create mode 100755 test/thread-replies
diff --git a/test/thread-replies b/test/thread-replies
new file mode 100755
index 000..a902691
--- /dev/null
+++ b/test/thread-replies
@@ -0,0 +1,144 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2013 Aaron Ecay
+#
+
+test_description='test of proper handling of in-reply-to and references headers
+
+This test makes sure that the thread structure in the notmuch database is
+constructed properly, even in the presence of non-RFC-compliant headers'
+
+. ./test-lib.sh
+
+test_begin_subtest "Use References when In-Reply-To is broken"
+test_subtest_known_broken
+add_message '[id]="foo at one.com"' \
+'[subject]=one'
+add_message '[in-reply-to]="mumble"' \
+'[references]=""' \
+'[subject]="Re: one"'
+output=$(notmuch show --format=json 'subject:one' | notmuch_json_show_sanitize)
+expected='[[[{"id": "foo at one.com",
+ "match": true,
+ "excluded": false,
+ "filename":
"/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-001",
+ "timestamp": 978709437,
+ "date_relative": "2001-01-05",
+ "tags": ["inbox", "unread"],
+ "headers": {"Subject": "one",
+ "From": "Notmuch Test Suite ",
+ "To": "Notmuch Test Suite ",
+ "Date": "Fri, 05 Jan 2001 15:43:57 +"},
+ "body": [{"id": 1,
+ "content-type": "text/plain",
+ "content": "This is just a test message (#1)\n"}]},
+ [[{"id": "msg-002 at notmuch-test-suite",
+ "match": true, "excluded": false,
+ "filename":
"/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-002",
+ "timestamp": 978709437, "date_relative": "2001-01-05",
+ "tags": ["inbox", "unread"], "headers": {"Subject": "Re: one",
+ "From": "Notmuch Test Suite ",
+ "To": "Notmuch Test Suite ",
+ "Date": "Fri, 05 Jan 2001 15:43:57 +"},
+ "body": [{"id": 1, "content-type": "text/plain",
+ "content": "This is just a test message (#2)\n"}]}, []]'
+expected=`echo "$expected" | notmuch_json_show_sanitize`
+test_expect_equal_json "$output" "$expected"
+
+test_begin_subtest "Prefer References to In-Reply-To"
+test_subtest_known_broken
+add_message '[id]="foo at two.com"' \
+'[subject]=two'
+add_message '[in-reply-to]=""' \
+'[references]=""' \
+'[subject]="Re: two"'
+output=$(notmuch show --format=json 'subject:two' | notmuch_json_show_sanitize)
+expected='[[[{"id": "foo at two.com",
+ "match": true, "excluded": false,
+ "filename":
"/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-003",
+ "timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox",
"unread"],
+ "headers": {"Subject": "two",
+ "From": "Notmuch Test Suite ",
+ "To": "Notmuch Test Suite ",
+ "Date": "Fri, 05 Jan 2001 15:43:57 +"},
+ "body": [{"id": 1, "content-type": "text/plain",
+ "content": "This is just a test message (#3)\n"}]},
+ [[{"id": "msg-004 at notmuch-test-suite", "match": true, "excluded": false,
+ "filename":
"/home/aecay/development/notmuch/notmuch-git/src/notmuch/test/tmp.thread-replies/mail/msg-004",
+ "timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox",
"unread"],
+ "headers": {"Subject": "Re: two",
+ "From": "Notmuch Test Suite ",
+ "To": "Notmuch Test Suite ",
+ "Date": "Fri, 05 Jan 2001 15:43:57 +"},
+ "body": [{"id": 1,
+ "content-type": "te
[PATCH 2/2] lib/database.cc: change how the parent of a message is calculated
Presently, the code which finds the parent of a message as it is being
added to the database assumes that the first Message-ID-like substring
of the In-Reply-To header is the parent Message ID. Some mail clients,
however, put stuff other than the Message-ID of the parent in the
In-Reply-To header, such as the email address of the sender of the
parent. This can fool notmuch.
The updated algorithm prefers the last Message ID in the References
header. The References header lists messages oldest-first, so the last
Message ID is the parent (RFC2822, p. 24). The References header is
also less likely to be in a non-standard
syntax (http://cr.yp.to/immhf/thread.html,
http://www.jwz.org/doc/threading.html). In case the References header
is not to be found, fall back to the old behavior.
V2 of this patch, incorporating feedback from Jani and (indirectly)
Austin.
---
lib/database.cc | 48 +---
test/thread-replies | 4
2 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 91d4329..52ed618 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -501,8 +501,10 @@ _parse_message_id (void *ctx, const char *message_id,
const char **next)
* 'message_id' in the result (to avoid mass confusion when a single
* message references itself cyclically---and yes, mail messages are
* not infrequent in the wild that do this---don't ask me why).
-*/
-static void
+ *
+ * Return the last reference parsed, if it is not equal to message_id.
+ */
+static char *
parse_references (void *ctx,
const char *message_id,
GHashTable *hash,
@@ -511,7 +513,7 @@ parse_references (void *ctx,
char *ref;
if (refs == NULL || *refs == '\0')
- return;
+ return NULL;
while (*refs) {
ref = _parse_message_id (ctx, refs, );
@@ -519,6 +521,17 @@ parse_references (void *ctx,
if (ref && strcmp (ref, message_id))
g_hash_table_insert (hash, ref, NULL);
}
+
+/* The return value of this function is used to add a parent
+ * reference to the database. We should avoid making a message
+ * its own parent, thus the following check.
+ */
+
+if (ref && strcmp(ref, message_id)) {
+ return ref;
+} else {
+ return NULL;
+}
}
notmuch_status_t
@@ -1510,28 +1523,33 @@ _notmuch_database_link_message_to_parents
(notmuch_database_t *notmuch,
{
GHashTable *parents = NULL;
const char *refs, *in_reply_to, *in_reply_to_message_id;
+const char *last_ref_message_id, *this_message_id;
GList *l, *keys = NULL;
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
parents = g_hash_table_new_full (g_str_hash, g_str_equal,
_my_talloc_free_for_g_hash, NULL);
+this_message_id = notmuch_message_get_message_id (message);
refs = notmuch_message_file_get_header (message_file, "references");
-parse_references (message, notmuch_message_get_message_id (message),
- parents, refs);
+last_ref_message_id = parse_references (message,
+ this_message_id,
+ parents, refs);
in_reply_to = notmuch_message_file_get_header (message_file,
"in-reply-to");
-parse_references (message, notmuch_message_get_message_id (message),
- parents, in_reply_to);
-
-/* Carefully avoid adding any self-referential in-reply-to term. */
-in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);
-if (in_reply_to_message_id &&
- strcmp (in_reply_to_message_id,
- notmuch_message_get_message_id (message)))
-{
+in_reply_to_message_id = parse_references (message,
+ this_message_id,
+ parents, in_reply_to);
+
+/* For the parent of this message, use the last message ID of the
+ * References header, if available. If not, fall back to the
+ * first message ID in the In-Reply-To header. */
+if (last_ref_message_id) {
+_notmuch_message_add_term (message, "replyto",
+ last_ref_message_id);
+} else if (in_reply_to_message_id) {
_notmuch_message_add_term (message, "replyto",
-_parse_message_id (message, in_reply_to, NULL));
+in_reply_to_message_id);
}
keys = g_hash_table_get_keys (parents);
diff --git a/test/thread-replies b/test/thread-replies
index a902691..28c2b1f 100755
--- a/test/thread-replies
+++ b/test/thread-replies
@@ -11,7 +11,6 @@ constructed properly, even in the presence of
non-RFC-compliant headers'
. ./test-lib.sh
test_begin_subtest "Use References when In-Reply-To is broken"
-test_subtest_known_broken
add_message '[id]="foo at one.com"' \
'[subject]=one'
add_message
[PATCH] test/README: mention the test_expect_equal_json and *sanitize* functions
also fix one typo --- test/README | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/test/README b/test/README index 81c232d..d12cff2 100644 --- a/test/README +++ b/test/README @@ -178,11 +178,18 @@ library for your script to use. test_expect_equal_file - Identical to test_exepect_equal, except that and + Identical to test_expect_equal, except that and are files instead of strings. This is a much more robust method to compare formatted textual information, since it also notices whitespace and closing newline differences. + test_expect_equal_json + + Identical to test_expect_equal, except that the two strings are + treated as JSON and canonicalized before equality testing. This is + useful to abstract away from whitespace differences in the expected + output and that generated by running a notmuch command. + test_debug
[PATCH] [emacs] Add an argument to notmuch-mua-mail
>From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmurri at gmail.com on Aug. 1: id:"877h6x6oor.fsf at veracitynetworks.com" Signed-off-by: Aaron Ecay --- emacs/notmuch-mua.el |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..23552ad 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -125,7 +125,8 @@ list." (message-goto-to)) (defun notmuch-mua-mail ( to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action ignored) "Invoke the notmuch mail composition window." (interactive) @@ -139,7 +140,8 @@ list." (notmuch-user-name) " <" (notmuch-user-primary-email) ">")) other-headers)) (message-mail to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8
[PATCH] [emacs] Add an argument to notmuch-mua-mail
>From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmurri at gmail.com on Aug. 1: id:"877h6x6oor.fsf at veracitynetworks.com" --- The previous version of this patch would break older emacsen. Not passing the return-action argument through to message-mail isn't nice, but the alternative is to conditionally pass it based on the emacs version, which is less nice. Thanks for the review Dmitry and Tomi. emacs/notmuch-mua.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..da31fdd 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -125,7 +125,8 @@ list." (message-goto-to)) (defun notmuch-mua-mail ( to subject other-headers continue - switch-function yank-action send-actions) + switch-function yank-action send-actions + return-action ignored) "Invoke the notmuch mail composition window." (interactive) -- 1.7.8
[PATCH] [emacs] Add an argument to notmuch-mua-mail
>From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmurri at gmail.com on Aug. 1: id:"877h6x6oor.fsf at veracitynetworks.com" --- This version of the patch adopts Dmitry's arg-passing approach, and also cleans up a long line (it is still slightly over 80 chars as I didn't see a better way to break it). Tomi, I don't see two interactive calls -- I think Emacs would complain if this happened. emacs/notmuch-mua.el | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..510c951 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -124,9 +124,10 @@ list." (message-goto-to)) -(defun notmuch-mua-mail ( to subject other-headers continue - switch-function yank-action send-actions) - "Invoke the notmuch mail composition window." +(defun notmuch-mua-mail ( to subject other-headers other-args) + "Invoke the notmuch mail composition window. + +OTHER-ARGS are passed through to `message-mail'." (interactive) (when notmuch-mua-user-agent-function @@ -135,11 +136,11 @@ list." (push (cons "User-Agent" user-agent) other-headers (unless (mail-header 'from other-headers) -(push (cons "From" (concat - (notmuch-user-name) " <" (notmuch-user-primary-email) ">")) other-headers)) +(push (cons "From" + (concat (notmuch-user-name) " <" (notmuch-user-primary-email) ">")) + other-headers)) - (message-mail to subject other-headers continue - switch-function yank-action send-actions) + (apply #'message-mail to subject other-headers other-args) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8
[PATCH] [emacs] Add an argument to notmuch-mua-mail
>From the emacs changelog: ** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and passes it to the mail user agent function. This argument specifies an action for returning to the caller after finishing with the mail. This is currently used by Rmail to delete a mail window. Under Emacs 24, notmuch breaks when this argument is passed to it by a function in another part of Emacs. One example of a functon that does this is report-emacs-bug -- so notmuch users cannot file emacs bug reports! This patch also adds a argument to the arg-list of this function, to future-proof against such changes. This is adapted from the approach taken by message-mail, a similar function built into emacs. This patch was originally submitted by richardmurri at gmail.com on Aug. 1: id:"877h6x6oor.fsf at veracitynetworks.com" --- emacs/notmuch-mua.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 8824b08..b525762 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -124,9 +124,10 @@ list." (message-goto-to)) -(defun notmuch-mua-mail ( to subject other-headers continue - switch-function yank-action send-actions) - "Invoke the notmuch mail composition window." +(defun notmuch-mua-mail ( to subject other-headers other-args) + "Invoke the notmuch mail composition window. + +OTHER-ARGS are passed through to `message-mail'." (interactive) (when notmuch-mua-user-agent-function @@ -138,8 +139,7 @@ list." (push (cons "From" (concat (notmuch-user-name) " <" (notmuch-user-primary-email) ">")) other-headers)) - (message-mail to subject other-headers continue - switch-function yank-action send-actions) + (apply #'message-mail to subject other-headers other-args) (message-sort-headers) (message-hide-headers) (set-buffer-modified-p nil) -- 1.7.8
[PATCH] Give a path name to mktemp in Makefile.local
On some systems (incl. OS X 10.6), mktemp expects an argument giving it the place to put the new temporary file. --- On my machine without this patch, make prints a message from mktemp about expecting an argument each time it is run. At some point, make got into a situation where it would print this message and exit cleanly, but not build any changed files. A "make clean" was necessary to kick it into working again. A disadvantage of this approach is that it drops an empty file into /tmp on every make run. It would be better to only create this file when doing "make debian-snapshot", but I am not sure how to do that (cleanly; my best idea is to put the build commands into a subshell and export an environment variable for the temp file). Any make/debian experts want to take a stab? Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index c94402b..6eb4b18 100644 --- a/Makefile.local +++ b/Makefile.local @@ -139,7 +139,7 @@ pre-release: mv $(TAR_FILE) $(DEB_TAR_FILE) releases .PHONY: debian-snapshot -debian-snapshot: TMPFILE := $(shell mktemp) +debian-snapshot: TMPFILE := $(shell mktemp /tmp/notmuch.XX) debian-snapshot: make VERSION=$(VERSION) clean cp debian/changelog $(TMPFILE) -- 1.7.8
[PATCH] Ignore dynamic libraries on OS X.
Parallel to ignoring .so for linux. --- .gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 9468e30..d64ec9f 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ notmuch.sym notmuch-shared notmuch.1.gz libnotmuch.so* +libnotmuch*.dylib *.[ao] *~ .*.swp -- 1.7.8
[PATCH] [emacs] Don't quote lambda forms
This generates byte-compiler warnings on (at least) current trunk versions of Emacs. The quote is not necessary; lambda forms are self-quoting. --- emacs/notmuch-crypto.el |4 +- emacs/notmuch-hello.el | 64 +- emacs/notmuch-maildir-fcc.el | 12 emacs/notmuch-message.el |8 ++-- emacs/notmuch-show.el| 20 ++-- emacs/notmuch.el | 20 ++-- 6 files changed, 64 insertions(+), 64 deletions(-) diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el index 44fccae..8974af1 100644 --- a/emacs/notmuch-crypto.el +++ b/emacs/notmuch-crypto.el @@ -63,7 +63,7 @@ mode." :group 'notmuch) (define-button-type 'notmuch-crypto-status-button-type - 'action '(lambda (button) (message (button-get button 'help-echo))) + 'action (lambda (button) (message (button-get button 'help-echo))) 'follow-link t 'help-echo "Set notmuch-crypto-process-mime to process cryptographic mime parts.") @@ -72,7 +72,7 @@ mode." (help-msg nil) (label "Signature not processed") (face 'notmuch-crypto-signature-unknown) -(button-action '(lambda (button) (message (button-get button 'help-echo) +(button-action (lambda (button) (message (button-get button 'help-echo) (cond ((string= status "good") (let ((fingerprint (concat "0x" (plist-get sigstatus :fingerprint diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 0582cae..d0dcf97 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -331,8 +331,8 @@ should be. Returns a cons cell `(tags-per-line width)'." (defvar notmuch-hello-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map widget-keymap) -(define-key map "v" '(lambda () "Display the notmuch version" (interactive) - (message "notmuch version %s" (notmuch-version +(define-key map "v" (lambda () "Display the notmuch version" (interactive) + (message "notmuch version %s" (notmuch-version (define-key map "?" 'notmuch-help) (define-key map "q" 'notmuch-kill-this-buffer) (define-key map "=" 'notmuch-hello-update) @@ -502,36 +502,36 @@ Complete list of currently available key bindings: (widget-insert "\n\n") (let ((start (point)) (nth 0)) - (mapc '(lambda (search) -(let ((widget-symbol (intern (format "notmuch-hello-search-%d" nth - (set widget-symbol - (widget-create 'editable-field - ;; Don't let the search boxes be - ;; less than 8 characters wide. - :size (max 8 - (- (window-width) -;; Leave some space -;; at the start and -;; end of the -;; boxes. -(* 2 notmuch-hello-indent) -;; 1 for the space -;; before the -;; `[save]' button. 6 -;; for the `[save]' -;; button. -1 6)) - :action (lambda (widget ignore) -(notmuch-hello-search (widget-value widget))) - search)) - (widget-insert " ") - (widget-create 'push-button - :notify (lambda (widget ignore) - (notmuch-hello-add-saved-search widget)) - :notmuch-saved-search-widget widget-symbol - "save")) -(widget-insert "\n") -(setq nth (1+ nth))) + (mapc (lambda (search) + (let ((widget-symbol (intern (format "notmuch-hello-search-%d" nth + (set widget-symbol + (widget-create 'editable-field + ;; Don't let the search boxes be + ;; less than 8 characters wide. + :size (max 8 +(- (window-width) + ;; Leave some space + ;; at the start and
[PATCH] Give a path name to mktemp in Makefile.local
On Sat, 17 Dec 2011 13:20:41 -0800, Jameson Graef Rollins wrote: > Not that I'm saying we shouldn't fix this issue, but just out of > curiosity, under what circumstances would someone want to call the > debian-snapshot target from a non-debian based system? That part of the makefile is called unconditionally, on all systems. So it doesn't matter if one does "make debian-snapshot" or not, the error is still generated. -- Aaron Ecay
[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.
David,
This patch doesn?t allow users to have their own settings for
shr-{inhibit,block}-images, since it forces these values to nil (via the
corresponding gnus variables).
(For those looking to follow the code, here?s the call path:
notmuch-show-mm-display-part-inline ->
mm-display-part ->
mm-display-inline -> (via lookup table)
mm-inline-text-html -> (via LUT)
mm-shr
The last function is where this objectionable rebinding happens)
Would a better approach be:
- clone the mm-shr function, replacing the vile gnus-specific code with
something functionally similar that takes the values from notmuch-foo
variables instead
- add '(notmuch-shr . notmuch-mm-shr) to the mm-text-html-renderer-alist
variable
- tell notmuch users to customize mm-text-html-renderer to 'notmuch-shr
if they want to use this renderer
The default values of the notmuch-{inhibit,block}-images variables
should prevent network requests for images being made by default* ? your
proposed nil/nil values don?t do this, AFAICT. Not doing network
requests for HTML email has been Spam Mitigation/Identity Protection 101
for a long time;** notmuch?s default behavior in this area has always
bothered me.
(Also, while we are on the subject of wonky defaults, why is
notmuch-show-all-multipart/alternative-parts set to t by default? This
is certainly not the best setting.)
FWIW, the patch does seem to allow using shr as the HTML renderer, but
for the reasons expressed I don?t think it solves the broader problem.
Aaron
* I think that inhibit -> nil, block -> ".*" should achieve this, but I?m
not sure/haven?t tested
** For example, Gmail makes you click a link at the top of an email
before it will load any network images contained therein.
--
Aaron Ecay
[PATCH] emacs: Add `notmuch-jump-to-recent-buffer'.
(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!) progn...set-buffer should be with-current-buffer or...eq...eq... would be cleaner as (memq major-mode '(foo bar baz)) Otherwise, LGTM -- 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
