[PATCH] emacs: Improved printing support.
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!
Add a keybinding to `notmuch-show-mode'.
emacs/Makefile.local |3 +-
emacs/notmuch-print.el | 85
emacs/notmuch-show.el | 53 ++
3 files changed, 140 insertions(+), 1 deletions(-)
create mode 100644 emacs/notmuch-print.el
diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 0c58b82..4fee0e8 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/notmuch-crypto.el \
- $(dir)/coolj.el
+ $(dir)/coolj.el \
+ $(dir)/notmuch-print.el
emacs_images := \
$(srcdir)/$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..77f10bb
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,85 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright © David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch. If not, see http://www.gnu.org/licenses/.
+;;
+;; Authors: David Edmondson d...@dme.org
+
+(defcustom notmuch-print-mechanism 'notmuch-print-lpr
+ How should printing be done?
+ :group 'notmuch
+ :type '(choice
+ (function :tag Use lpr notmuch-print-lpr)
+ (function :tag Use ps-print notmuch-print-ps-print)
+ (function :tag Use ps-print then evince
notmuch-print-ps-print/evince)
+ (function :tag Use muttprint notmuch-print-muttprint)
+ (function :tag Use muttprint then evince
notmuch-print-muttprint/evince)
+ (function :tag Using a custom function)))
+
+;; Utility functions:
+
+(defun notmuch-print-run-evince (file)
+ View FILE using 'evince'.
+ (start-process evince nil evince file))
+
+(defun notmuch-print-run-muttprint (optional output)
+ Pass the contents of the current buffer to 'muttprint'.
+
+Optional OUTPUT allows passing a list of flags to muttprint.
+ (apply #'call-process-region (point-min) (point-max)
+;; Reads from stdin.
+muttprint
+nil nil nil
+;; Show the tags.
+--printed-headers Date_To_From_CC_Newsgroups_*Subject*_/Tags/
+output))
+
+;; User-visible functions:
+
+(defun notmuch-print-lpr (msg)
+ Print a message buffer using lpr.
+ (lpr-buffer))
+
+(defun notmuch-print-ps-print (msg)
+ Print a message buffer using the ps-print package.
+ (let ((subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer)))
+
+(defun notmuch-print-ps-print/evince (msg)
+ Preview a message buffer using ps-print and evince.
+ (let ((ps-file (make-temp-file notmuch))
+ (subject (plist-get (notmuch-show-get-prop :headers msg) :Subject)))
+(rename-buffer subject t)
+(ps-print-buffer ps-file)
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-muttprint (msg)
+ Print a message using muttprint.
+ (notmuch-print-run-muttprint))
+
+(defun notmuch-print-muttprint/evince (msg)
+ Preview a message buffer using muttprint and evince.
+ (let ((ps-file (make-temp-file notmuch)))
+(notmuch-print-run-muttprint (list --printer (concat TO_FILE:
ps-file)))
+(notmuch-print-run-evince ps-file)))
+
+(defun notmuch-print-message (msg)
+ Print a message using the user-selected mechanism.
+ (funcall notmuch-print-mechanism msg))
+
+(provide 'notmuch-print)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 797f94b..db25565 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -34,6 +34,7 @@
(require 'notmuch-wash)
(require 'notmuch-mua)
(require 'notmuch-crypto)
+(require 'notmuch-print)
(declare-function notmuch-call-notmuch-process notmuch (rest args))
(declare-function notmuch-fontify-headers notmuch nil)
@@ -186,6 +187,52 @@ indentation.
mm-handle ( (notmuch-count-attachments mm-handle) 1
(message Done))
+(defun notmuch-show-with-message-as-text (fn)
+ Apply FN to a text representation of the current message.
+
+FN is called with one argument, the message properties. It should
+operation on
Re: [PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions
Very happy with the overall ideas. On Tue, 17 Jan 2012 10:05:26 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: -(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. (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 ((tag-function 'notmuch-show-add-tag)) +(if remove + (setq tag-function 'notmuch-show-remove-tag)) This seems odd. How about: (let ((tag-function (if remove 'notmuch-show-remove-tag 'notmuch-show-add-tag))) ... +(loop do (funcall tag-function tag) + until (not (notmuch-show-goto-message-next) Otherwise good. pgpPEDIZL1lXa.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/6] emacs: break out thread navigation from notmuch-show-archive-thread
+1. pgpiBtWVmyHt6.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/6] emacs: add message archiving functions
+1. pgpmQNrG3IoQL.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end
On Tue, 17 Jan 2012 10:05:29 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: -(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 need for brackets around `r'. Please put initialised local variables before uninitialised. (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)) Can you explain in words how this is expected to behave please? pgp1rxft2rnCd.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] emacs: modify the default show-mode key bindings for archiving
+1. pgpxIDMWtKOaN.pgp Description: PGP signature ___ 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: On Tue, 17 Jan 2012 15:10:40 -0500, Aaron Ecay aarone...@gmail.com wrote: This should be a docstring instead of a comment. (This applies equally to the old version) We're not currently in the habit of adding doc strings for non-interactive programs. Do we need to go down that route? They are nice to have, especially if we already have the comment. pgpTnlAGX8683.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6
On Tue, 17 Jan 2012 17:25:46 -0500, Austin Clements amdra...@mit.edu wrote:
Quoth Thomas Jost on Jan 17 at 11:50 am:
+#ifdef GMIME_26
+/* sig_list may be created in both above cases, so we need to
+ * cleanly handle it here. */
+if (node-sig_list) {
+ GMimeSignatureList **proxy =
+ talloc (node, GMimeSignatureList *);
This doesn't need to be split into two lines.
+ *proxy = node-sig_list;
+ talloc_set_destructor (proxy, _signature_list_free);
+}
+#else
if (node-verify_attempted !node-sig_validity)
fprintf (stderr, Failed to verify signed part: %s\n,
(err ? err-message : no error explanation given));
+#endif
I'd rather see the above as a separate #ifdef GMIME_26 and #ifndef
GMIME_26, since they aren't logical alternates of each other.
That reminds me that it should then be like GMIME_ATLEAST_26, so
that this might be useful when GMIME 2.6 is available...
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: on deleting messages
Add the bindings. Provide documentation that makes it clear that they just add tags and never delete anything. pgp3b1CEVBlBs.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: bind s to `notmuch-search' in notmuch-hello buffer
Looks fine. pgpvjhm6aqI2W.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] emacs: use a single history for all searches
On Tue, 17 Jan 2012 23:34:09 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: There are two ways to do search in Emacs UI: search widget in notmuch-hello buffer and `notmuch-search' function bound to s. Before the change, these search mechanisms used different history lists. The patch makes notmuch-hello search use the same history list as `notmuch-search' function. The test output updates included here should be with the previous patch, shouldn't they? -(defun notmuch-search (query optional oldest-first target-thread target-line continuation) - Run \notmuch search\ with the given query string and display results. +(defun notmuch-search (optional query oldest-first target-thread target-line continuation) + Run \notmuch search\ with the given `query' and display results. -The optional parameters are used as follows: +If `query' is nil, it is read interactively from the minibuffer. +Other optional parameters are used as follows: oldest-first: A Boolean controlling the sort order of returned threads target-thread: A thread ID (with the thread: prefix) that will be made current if it appears in the search results. target-line: The line number to move to if the target thread does not appear in the search results. - (interactive (list (notmuch-read-query Notmuch search: ))) + (interactive) + (if (null query) + (setq query (notmuch-read-query Notmuch search: )) +(setq query (notmuch-trim query)) +(let ((history-delete-duplicates t)) + (add-to-history 'notmuch-search-history query))) Should user-typed queries be trimmed? pgp9ycoMxMOWc.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/3] emacs: bind s to `notmuch-hello-search' in notmuch-hello buffer
+1. pgpZyJWo7ibRf.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 3/3] search: Support automatic tag exclusions
On Tue, 17 Jan 2012 15:32:11 -0500, Austin Clements amdra...@mit.edu wrote:
Quoth David Edmondson on Jan 17 at 9:08 am:
On Mon, 16 Jan 2012 15:16:24 -0700, Jeremy Nickurak jer...@nickurak.ca
wrote:
On Mon, Jan 16, 2012 at 12:28, Austin Clements amdra...@mit.edu wrote:
Having deleted and spam as default settings in the configuration
file might be more reasonable.
If I read correctly:
1) If no exclude options are in the config file, none should be used.
Yes.
2) On notmuch setup, deleted and spam should be added to
.notmuch-config
I might argue between 'should' and 'could', but the sense is correct.
Oh, I think I see. I don't know if I can do precisely that, since the
config code doesn't know if it's being called from setup, but is
something like this essentially what you're suggesting?
if (notmuch_config_get_auto_exclude_tags (config, tmp) == NULL) {
if (is_new) {
const char *tags[] = { deleted, spam };
notmuch_config_set_auto_exclude_tags (config, tags, 2);
} else {
notmuch_config_set_auto_exclude_tags (config, NULL, 0);
}
}
(where is_new is TRUE if this is a brand-new config file)
I'm not sure, as I haven't looked at the configuration code at
all, sorry.
Something must create the initial configuration file if none exists. I'd
be okay with that code adding 'deleted' and 'spam' to the excluded list.
This would mean that an existing user would see no change without taking
some action (adding the tags to the configuration file) and a new user
would see the new behaviour (automatic exclusion).
I'm not completely sure that automatically adding the exclusion of the
specified tags via the configuration file for new users is a great
idea. It seems as though it will lead to confusion for someone at some
point.
pgplDqY6w09FW.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end
On Wed, 18 Jan 2012 08:12:27 +, David Edmondson d...@dme.org wrote: No need for brackets around `r'. Please put initialised local variables before uninitialised. Yeah, that's another comment of Aron's that I forgot to fix this time around. Sorry about that. (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)) Can you explain in words how this is expected to behave please? If there is not another message, but there is a parent buffer and the pop-at-end variable is set, kill this buffer, go the parent, and move to the next thread. Otherwise, go to the max point in the buffer. Do you see a problem? The one thing I do realize now is that the behavior might be slightly strange if the parent buffer is itself a show buffer. In that case, the forward-line part doesn't make any sense. It should check that the parent is a search buffer first. It should also use the notmuch-search function to jump to the next thread (notmuch-search-next-thread). The notmuch-show-next-thread function could use the same improvements. jamie. pgpueL0rYeasQ.pgp Description: PGP signature ___ 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 3/3] search: Support automatic tag exclusions
On Wed, 18 Jan 2012 08:38:23 +, David Edmondson d...@dme.org wrote: Something must create the initial configuration file if none exists. I'd be okay with that code adding 'deleted' and 'spam' to the excluded list. This would mean that an existing user would see no change without taking some action (adding the tags to the configuration file) and a new user would see the new behaviour (automatic exclusion). What you describe is indeed how it currently works. For new users or old users who rerun setup, the config file will automatically include the exclusions. Otherwise, users will see no change. I'm not completely sure that automatically adding the exclusion of the specified tags via the configuration file for new users is a great idea. It seems as though it will lead to confusion for someone at some point. Without any keys pre-bound to add deleted or spam tags, it probably won't make much difference for new users. And as long as it's documented, users will be warned of the behavior. Reading the config file would also make it clear how the variable changes behavior. jamie. pgpD4puN5LjZv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end
On Wed, 18 Jan 2012 00:47:11 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: (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)) Can you explain in words how this is expected to behave please? Do you see a problem? Not a problem, just trying to understand the behaviour (I have to revive my advance/rewind patches at some point). If there is not another message, but there is a parent buffer and the pop-at-end variable is set, kill this buffer, go the parent, and move to the next thread. Otherwise, go to the max point in the buffer. I'm used to the cursor going to the bottom of the thread to let me know that I reached the end, then I hit 'space' and move on to the next thread. Will that behaviour be retained with this patch? (Well, including your other patch which seemed to set `pop-at-end'.) It's one of those things that I have to try out to understand properly I expect. pgpNJfgx1uQ3o.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] test: Add `test_emacs_expect_t'.
On Tue, 17 Jan 2012 15:09:22 +, David Edmondson d...@dme.org wrote:
On Tue, 17 Jan 2012 18:49:36 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
+ # We cannot call 'test_emacs' in a subshell, because
+ # the setting of EMACS_SERVER would not persist
+ # throughout a sequence of tests, so we use a
+ # temporary file.
+ tmp=$TMPDIR; if [ -z $tmp ]; then tmp=/tmp; fi
+ output=$tmp/test_emacs_output.$$
+ test_emacs $1 ${output}
+ result=$(cat ${output})
+ rm -f ${output}
I wonder if there is any bash trick which can help here?
I'm not aware of one, but I'm not a bash expert.
No shell trick possible there.
Another option is to start emacs server before using test_emacs in
subshell. See emacs-subject-to-filename for an example. I think this
is a better option than using a temporary file.
I think that's a very poor option. Forcing knowledge the breakage into
all of the users may make applying any future fix more difficult.
The alternative would be to replace
emacsclient --socket-name=$EMACS_SERVER --eval (progn $@)
with something like:
case $1 in --stdout-to-output)
shift
output=$(emacsclient --socket-name=$EMACS_SERVER --eval (progn $@))
return
esac
emacsclient --socket-name=$EMACS_SERVER --eval (progn $@)
Tomi
___
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 Mon, 16 Jan 2012 17:03:44 +, David Edmondson d...@dme.org wrote: On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@praet.org wrote: Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch', eliminating the need to hog yet another keybind. ... diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ef4dcc7..539b3a0 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag. (defun notmuch () Run notmuch and display saved searches, known tags, etc. (interactive) - (notmuch-hello)) + (let* ((old-buffer (current-buffer)) +(interesting-buffers + (delq nil (mapcar (lambda (b) + (if (notmuch-interesting-buffer b) b)) + (buffer-list +(next-buffer (first + (delq nil (mapcar (lambda (b) + (unless (eq old-buffer b) b)) + interesting-buffers) This feels _less_ lispy. [...] True. I simply re-implemented `delete-if-not' in order to prevent having to require the `cl' package at runtime. (why on Earth isn't there an equivalent function in plain Elisp ?!?) $ sed -e s/C\?Lisp\(y\|'ier\)/Elispy/ $COMMIT_MSG [...] Any occurrences of '(delq nil ...)' strike me as odd. [...] How so? Lacking a flexible way to conditionally remove elements from a list (that doesn't require the `cl' package in some way or another), a combination of `mapcar' and `delq' seemed like the easiest approach. (AFAIK; Please correct me if (when) I'm wrong!) [...] What's wrong with '(loop ... collect ...)'? Nothing at all. I was fixing my own patch [1] without resorting to requiring the `cl' package at runtime :) Would be nice if we could get rid of the compile-time dependency as well, though. Fresh patch to that effect follows. Feel free to disregard it, just bikesheddin'... +(if next-buffer + (progn + (switch-to-buffer next-buffer) + (bury-buffer old-buffer)) + (notmuch-hello Integrating with `notmuch' is fine with me. Peace -- Pieter [1] id:1326710551-23122-1-git-send-email-pie...@praet.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] [PATCH v3] emacs: rewrite `notmuch-cycle-notmuch-buffers'
Get rid of the compile-time `cl' requirement for this particular function. --- emacs/notmuch.el | 40 ++-- 1 files changed, 22 insertions(+), 18 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ef4dcc7..2426c0a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1084,24 +1084,28 @@ current search results AND that are tagged with the given tag. If the current buffer is the only notmuch buffer, bury it. If no notmuch buffers exist, run `notmuch'. (interactive) - - (let (start first) -;; If the current buffer is a notmuch buffer, remember it and then -;; bury it. -(when (notmuch-interesting-buffer (current-buffer)) - (setq start (current-buffer)) - (bury-buffer)) - -;; Find the first notmuch buffer. -(setq first (loop for buffer in (buffer-list) -if (notmuch-interesting-buffer buffer) -return buffer)) - -(if first - ;; If the first one we found is any other than the starting - ;; buffer, switch to it. - (unless (eq first start) - (switch-to-buffer first)) + (let* ((old-buffer (current-buffer)) +(next-buffer (first + ;; Find interesting buffers: + ;; Loop over all existing buffers and return those that + ;; satisfy the predicate (`notmuch-interesting-buffer' and + ;; not `eq' to current buffer) integrally; All others are + ;; replaced with `nil'. Then strip out all `nil's using + ;; `delq'. Basically a re-implementation of `cl' package's + ;; `delete-if-not'. + (delq nil + (mapcar (lambda (b) +(and (notmuch-interesting-buffer b) + (not (eq old-buffer b)) + b)) + (buffer-list)) + +;; If there's a next buffer, switch to it and bury the +;; original current buffer. Otherwise run `notmuch-hello'. +(if next-buffer + (progn + (switch-to-buffer next-buffer) + (bury-buffer old-buffer)) (notmuch (setq mail-user-agent 'notmuch-user-agent) -- 1.7.8.1 ___ 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 Mon, 16 Jan 2012 23:10:27 +0200, Jani Nikula j...@nikula.org wrote: On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@praet.org wrote: Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch', eliminating the need to hog yet another keybind. What does merge mean here? [...] One function ought to be enough for anybody. ? :) [1] [...] Will it still be possible for me to hit one key to unconditionally get to notmuch-hello, and another to cycle through the buffers? I wouldn't want to lose that ability. Sure, but then your new key should be bound to `notmuch' instead of `notmuch-cycle-notmuch-buffers', and the key originally bound to `notmuch' should be remapped to `notmuch-hello'. --- emacs/notmuch.el | 40 ++-- 1 files changed, 14 insertions(+), 26 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ef4dcc7..539b3a0 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag. (defun notmuch () Run notmuch and display saved searches, known tags, etc. (interactive) - (notmuch-hello)) + (let* ((old-buffer (current-buffer)) +(interesting-buffers + (delq nil (mapcar (lambda (b) + (if (notmuch-interesting-buffer b) b)) + (buffer-list +(next-buffer (first + (delq nil (mapcar (lambda (b) + (unless (eq old-buffer b) b)) + interesting-buffers) +(if next-buffer + (progn + (switch-to-buffer next-buffer) + (bury-buffer old-buffer)) + (notmuch-hello notmuch-cycle-notmuch-buffers pretty much explains in the name what it does, but additionally it has documentation, and explanatory comments. Please don't drop those. Agreed. Less intrusive patch available [2]. BR, Jani (defun notmuch-interesting-buffer (b) Is the current buffer of interest to a notmuch user? @@ -1078,31 +1091,6 @@ current search results AND that are tagged with the given tag. message-mode ;;;###autoload -(defun notmuch-cycle-notmuch-buffers () - Cycle through any existing notmuch buffers (search, show or hello). - -If the current buffer is the only notmuch buffer, bury it. If no -notmuch buffers exist, run `notmuch'. - (interactive) - - (let (start first) -;; If the current buffer is a notmuch buffer, remember it and then -;; bury it. -(when (notmuch-interesting-buffer (current-buffer)) - (setq start (current-buffer)) - (bury-buffer)) - -;; Find the first notmuch buffer. -(setq first (loop for buffer in (buffer-list) -if (notmuch-interesting-buffer buffer) -return buffer)) - -(if first - ;; If the first one we found is any other than the starting - ;; buffer, switch to it. - (unless (eq first start) - (switch-to-buffer first)) - (notmuch (setq mail-user-agent 'notmuch-user-agent) -- 1.7.8.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter [1] http://www.computerworld.com/s/article/9101699 [2] id:1326881084-25432-1-git-send-email-pie...@praet.org ___ 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 16:43:06 -0500, Aaron Ecay aarone...@gmail.com wrote: 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. [...] Excellent suggestion! Amended patch follows. [...] 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. Not sure how that would pan out. It's fairly common behaviour to put one or more spaces after a inline Message-Id, so I don't think such a limitation would be warmly recepted. -- Aaron Ecay Peace -- Pieter ___ 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 11:03:09 +0100, Pieter Praet pie...@praet.org wrote: [...] What's wrong with '(loop ... collect ...)'? Nothing at all. I was fixing my own patch [1] without resorting to requiring the `cl' package at runtime :) Would be nice if we could get rid of the compile-time dependency as well, though. Can you explain why it's necessary at runtime? pgpBb36VLbqMG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] Make buttons for attachments allow viewing as well as saving
+(defun notmuch-show-view-part (message-id nth optional filename content-type ) + (notmuch-with-temp-part-buffer message-id nth +;; set mm-inlined-types to nil to force an external viewer +(let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + ;; We override mm-save-part as notmuch-show-save-part is better + ;; since it offers the filename + (flet ((mm-save-part (rest args) (ignore))) + (or (mm-display-part handle) + (notmuch-show-save-part message-id nth filename content-type)) Is that a reasonable solution? It's *probably* safe to depend on the result of mm-display-part, but you can avoid the question altogether by simply calling notmuch-show-save-part from your flet mm-save-part. E.g., (flet ((mm-save-part (rest args) (notmuch-show-save-part message-id nth filename content-type))) (mm-display-part handle)) Unfortunately that does not work since mm-display-part has a local variable filename. I could copy the variables to some notmuch prefixed variables but maybe there is some obvious quoting to avoid the problem? (I can't easily check now as the gnu site is closed for the day.) Best wishes Mark ___ 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 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@praet.org wrote: [...] What's wrong with '(loop ... collect ...)'? Nothing at all. I was fixing my own patch [1] without resorting to requiring the `cl' package at runtime :) Would be nice if we could get rid of the compile-time dependency as well, though. Can you explain why it's necessary at runtime? Because otherwise `remove-if-not' and `member-if-not' would be void, as you alluded to previously [1,2]. Peace -- Pieter [1] id:cunvcob52ku@hotblack-desiato.hh.sledj.net [2] id:cun1uqz50p4@hotblack-desiato.hh.sledj.net ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: always report missing prereqs, independent of `--verbose' option
When tests are skipped due to missing prereqs, those prereqs are only
displayed when running with the `--verbose' option. This is essential
information when troubleshooting, so always send to stdout.
---
test/test-lib.sh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index d1fbc05..6560628 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -673,8 +673,8 @@ test_skip () {
test_check_missing_external_prereqs_ () {
if test -n $test_subtest_missing_external_prereqs_; then
- say_color skip 3 missing prerequisites:
- echo $test_subtest_missing_external_prereqs_ 3
+ say_color skip 1 missing prerequisites:
+ echo $test_subtest_missing_external_prereqs_ 1
test_report_skip_ $@
else
false
--
1.7.8.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/3 v3] emacs: colorize buttonized 'id:' links depending on the target message's state
* emacs/notmuch-show.el (notmuch-show-buttonized-link-colors): - new defcustom, allows toggling colorization of buttonized links. (notmuch-show-buttonized-link-available), (notmuch-show-buttonized-link-available-and-unread), (notmuch-show-buttonized-link-missing): - new faces for buttonized id: links. (notmuch-show-found-target-p): - add optional arg SUBQUERY to allow addition filtering, eg. with tag:unread. (notmuch-show-buttonize-links): - tweak `Message-Id' regexp: less greedy matching. - 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 different colors. --- [Forgot to cc the list, apologies for the dupes.] I've also noticed that Message-Id's from `git send-email' don't get colorized (but do get buttonized) for some reason. Thus, would appreciate some assistance with the regexp. v2: - add `notmuch-show-buttonized-link-colors': new defcustom, allows toggling colorization of buttonized links, to address unquestionable concerns re performance, voiced by David Edmondson [1]. - ... and some minor refactoring v3: - tweak `Message-Id' regexp: mock Message-Id's shouldn't be matched, as pointed out by Aaron Ecay [2]. [1] id:cun4nvv50s6@hotblack-desiato.hh.sledj.net [2] id:m2sjjfb9xx@gmail.com emacs/notmuch-show.el | 47 +++ 1 files changed, 43 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 244824a..deac9a6 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -798,6 +798,38 @@ current buffer, if possible. (defvar notmuch-show-buffer-name nil) (make-variable-buffer-local 'notmuch-show-buffer-name) +(defcustom notmuch-show-buttonized-link-colors t + Colorize buttonized links depending on their target's state. + +Also see `notmuch-show-buttonized-link-available', + `notmuch-show-buttonized-link-available-and-unread', + `notmuch-show-buttonized-link-missing'. + +Might impact performance. + :type 'boolean + :group 'notmuch-show) + +(defface notmuch-show-buttonized-link-available + '((t (:inherit goto-address-mail-face :foreground blue))) + Face used for buttonized links to messages which are present +in the mail store. + :group 'notmuch-show + :group 'notmuch-faces) + +(defface notmuch-show-buttonized-link-available-and-unread + '((t (:inherit goto-address-mail-face :foreground green))) + Face used for buttonized links to messages which are present +in the mail store, and are tagged `unread'. + :group 'notmuch-show + :group 'notmuch-faces) + +(defface notmuch-show-buttonized-link-missing + '((t (:inherit goto-address-mail-face :foreground red))) + Face used for buttonized links to messages which are NOT +present in in the mail store. + :group 'notmuch-show + :group 'notmuch-faces) + (defun notmuch-show-buttonize-links (start end) Buttonize URLs and mail addresses between START and END. @@ -806,7 +838,7 @@ a corresponding notmuch search. (goto-address-fontify-region start end) (save-excursion (goto-char start) -(while (re-search-forward id:\\(\?\\)[^[:space:]\]+\\1 end t) +(while (re-search-forward id:\\(\?\\)\[^ \t\@\]\+@[^ \t\]\+\\1 end t) (let ((message-id (match-string-no-properties 0)) (string-start (match-beginning 0)) (string-end (match-end 0))) @@ -817,7 +849,14 @@ a corresponding notmuch search. (notmuch-show-if-found ,message-id)) 'follow-link t 'help-echo Mouse-1, RET: search for this message - 'face goto-address-mail-face) + 'face (if notmuch-show-buttonized-link-colors + (cond +((notmuch-show-found-target-p message-id and tag:unread) + 'notmuch-show-buttonized-link-available-and-unread) +((notmuch-show-found-target-p message-id nil) + 'notmuch-show-buttonized-link-available) +(t 'notmuch-show-buttonized-link-missing)) + 'goto-address-mail-face)) ;;;###autoload (defun notmuch-show (thread-id optional parent-buffer query-context buffer-name crypto-switch) @@ -910,8 +949,8 @@ thread id. If a prefix is given, crypto processing is toggled. (notmuch-kill-this-buffer) (notmuch-show-worker thread-id parent-buffer query-context buffer-name process-crypto))) -(defun notmuch-show-found-target-p (target) - (let ((args `(count ,target))) +(defun notmuch-show-found-target-p (target optional subquery) + (let ((args `(count ,target ,(or subquery ( (string-to-number (with-output-to-string
Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'
On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet pie...@praet.org wrote: On Wed, 18 Jan 2012 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@praet.org wrote: [...] What's wrong with '(loop ... collect ...)'? Nothing at all. I was fixing my own patch [1] without resorting to requiring the `cl' package at runtime :) Would be nice if we could get rid of the compile-time dependency as well, though. Can you explain why it's necessary at runtime? Because otherwise `remove-if-not' and `member-if-not' would be void, as you alluded to previously [1,2]. Ah, not macros. Sorry for being slow. pgpp0gnSDl9OJ.pgp Description: PGP signature ___ 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 13:03:06 +, David Edmondson d...@dme.org wrote: Hey, look - I deliberately pressed 'r' instead of 'R'! You have remarkably malleable muscle memory. Care to donate some to the less fortunate ? :) On Wed, 18 Jan 2012 12:57:53 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet pie...@praet.org wrote: On Wed, 18 Jan 2012 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@praet.org wrote: [...] What's wrong with '(loop ... collect ...)'? Nothing at all. I was fixing my own patch [1] without resorting to requiring the `cl' package at runtime :) Would be nice if we could get rid of the compile-time dependency as well, though. Can you explain why it's necessary at runtime? Because otherwise `remove-if-not' and `member-if-not' would be void, as you alluded to previously [1,2]. Ah, not macros. Sorry for being slow. But, loop is a macro, so the loop collector variant (which I originally suggested) would be fine with just loading cl during compilation. Absolutely. 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. So as said [5], feel free to disregard it, just bikesheddin'... All of my patches in this thread belong in notmuch::obsolete. Peace -- Pieter [1] id:1326710551-23122-1-git-send-email-pie...@praet.org [2] id:87wr8rc2ex@praet.org [3] id:87ehuzl5fg@nikula.org [4] id:87r4yza95m@praet.org [5] id:87fwfd8h0i@praet.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: add invisible dot instead of space at the end of notmuch-hello search box
On Tue, 17 Jan 2012 19:55:34 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: This makes `show-trailing-whitespace' happy, i.e. it does not mark the whole search box line as trailing spaces. Since the dot is invisible, this change makes no visible difference for `notmuch-hello'. --- emacs/notmuch-hello.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 02017ce..38846ef 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -508,9 +508,12 @@ Complete list of currently available key bindings: (length Search: ))) :action (lambda (widget rest ignore) (notmuch-hello-search (widget-value widget - ;; add an invisible space to make `widget-end-of-line' ignore - ;; trailine spaces in the search widget field - (widget-insert ) + ;; Add an invisible dot to make `widget-end-of-line' ignore + ;; trailing spaces in the search widget field. A dot is used + ;; instead of a space to make `show-trailing-whitespace' + ;; happy, i.e. avoid it marking the whole line as trailing + ;; spaces. + (widget-insert .) (put-text-property (1- (point)) (point) 'invisible t) (widget-insert \n) -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch +1 Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: always report missing prereqs, independent of `--verbose' option
On Wed, 18 Jan 2012 13:19:41 +0100, Pieter Praet pie...@praet.org wrote:
When tests are skipped due to missing prereqs, those prereqs are only
displayed when running with the `--verbose' option. This is essential
information when troubleshooting, so always send to stdout.
---
Instead of this the test suite could be enchanged so that
full log of the execution is stored somewhere and path
to that file is displayed at the end of test. Generally,
all output could stay available after tests exit so that
those could be investigated furtner.
(I tried to grep 'missing prerequisites' after running test
but did not find the info. the file opened for 3 has been
deleted already?)
Now I just see huge amounts of missing prerequisites: emacs(1)
in my output (I presume that doesn't happen due to my
hack to hide emacs).
But well, I'm not against applying this patch -- just that
the test system starts to get so rotten touching it gives
shivers...
Tomi
test/test-lib.sh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index d1fbc05..6560628 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -673,8 +673,8 @@ test_skip () {
test_check_missing_external_prereqs_ () {
if test -n $test_subtest_missing_external_prereqs_; then
- say_color skip 3 missing prerequisites:
- echo $test_subtest_missing_external_prereqs_ 3
+ say_color skip 1 missing prerequisites:
+ echo $test_subtest_missing_external_prereqs_ 1
test_report_skip_ $@
else
false
--
1.7.8.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
compressing header lines - quick prototype
Here's something that I was playing with this morning. It's not finished, but has some nasty corners, so I'd like to solicit opinion on whether it's worth finishing. When faced with a long thread where most of the messages are closed, it might be convenient to hide large stretches of closed headers. This code attempts to do that. You can run `dme/notmuch-show-compress-headers' manually in a `notmuch-show-mode' buffer or (for the terminally brave) attach the same function to `notmuch-show-hook'. There are still problems with the nested invisibility specs and the current `notmuch-show-advance-and-archive' and friends get confused, but it should be enough for you to get the idea. After using it for a bit I came to the conclusion that it's not worth pursuing, but figured that I'd post it to get feedback from others. bins6DRyb7D5f.bin Description: application/emacs-lisp pgpeOx4jfEbvt.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RFC: tag macros
Hi All; Here is a very early stage proposal to provide tagging macros for notmuch show mode. The idea is that user defines a mapping from single key to a sequence of tagging operations. It might be nice if there as some kind of pop-up menu, or at least a prompt, but I didn't do that so far. The advantage of this rather than just writing lots of little lambdas is that it combines adding and deleting, and it could be done via customize. As provided, the code should just paste into .emacs, and with a little editing into notmuch-show.el. % cut here (eval-after-load 'notmuch-show '(define-key notmuch-show-mode-map t 'notmuch-show-apply-tag-macro)) (setq notmuch-show-tag-macro-alist (list '(p +notmuch::patch +notmuch::needs-review) '(r +notmuch::review) '(o +notmuch::patch +notmuch::obsolete -notmuch::needs-review) '(m +notmuch::patch +notmuch::moreinfo -notmuch::needs-review))) (defun notmuch-show-apply-tag-macro (key) (interactive k) (let ((macro (assoc key notmuch-show-tag-macro-alist))) (apply 'notmuch-show-add-or-del-tags (cdr macro (defun notmuch-show-add-or-del-tags (rest add-or-dels) Add or delete tags to/from the current message. (let* ((current-tags (notmuch-show-get-tags)) (new-tags (notmuch-show-add-or-del-tags-worker current-tags add-or-dels))) (unless (equal current-tags new-tags) (apply 'notmuch-tag (notmuch-show-get-message-id) add-or-dels) (notmuch-show-set-tags new-tags (defun notmuch-show-add-or-del-tags-worker (current-tags add-or-dels) Remove any tags in `add-or-del' prefixed with `-' from `current-tags', add any prefixed with `+' and return the result. (let (adds deletes) (mapc (lambda (tag-str) (if (string-match ^\\([+\-]\\)\\(.*\\) tag-str) (let ((op (match-string 1 tag-str)) (tag (match-string 2 tag-str))) (if (equal op +) (setq adds (cons tag adds)) (setq deletes (cons tag deletes (error %s: does not start with + or - tag-str))) add-or-dels) (notmuch-show-del-tags-worker (notmuch-show-add-tags-worker current-tags adds) deletes))) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[feature request] thread-based queries
Hi everyone, A recent discussion on alot's issue tracker[0] made it clear that it might be useful to have a thread-based matching for queries as an alternative to the current message based approach: Consider a thread with two messages, one has a single tag 'flagged', the other a single tag 'unread'. Now the thread doesn't match tag:flagged AND tag:unread as it doesn't contain any matching messages. However, listing the tags of this thread accumulates to ['flagged', 'unread']. As far as I know, there is no way one can tell notmuch to evaluate the query with threads as atomic entities instead of messages so that the thread in the example above matches. I would like to see such a switch in libnotmuch and the python bindings, maybe as parameter to `notmuch_query_create` or as something similar to `notmuch_query_set_sort`. I am aware that I can simulate the intended behaviour by rewriting the query myself, but I think such a feature makes sense not only for alot users and should be implemented at a lower level. Moreover, I wouldn't be surprised if doing this at a library level is less painful than higher up as Xapian has to parse query formulae anyway and hence should offer some convenience methods for dealing with them. Please correct me if I'm wrong here or have just overlooked previous discussions/solutions for this issue. Best, /p [o]: https://github.com/pazz/alot/issues/270 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] test: Add `test_emacs_expect_t'.
On Tue, 17 Jan 2012 14:07:03 +, David Edmondson d...@dme.org wrote:
Add a new test function to allow simpler testing of emacs
functionality.
`test_emacs_expect_t' takes one argument - a list expression to
evaluate. The test passes if the expression returns `t', otherwise it
fails and the output is reported to the tester.
---
Re-worked as Dmitry suggested.
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7c9ce24..4b05760 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -503,6 +503,39 @@ test_expect_equal_file ()
fi
}
+test_emacs_expect_t () {
+ test $# = 1 || error bug in the test script: not 1 parameter to
test_emacs_expect_t
+
+ # Run the test.
+ if ! test_skip $test_subtest_name
+ then
+ # We cannot call 'test_emacs' in a subshell, because
+ # the setting of EMACS_SERVER would not persist
+ # throughout a sequence of tests, so we use a
+ # temporary file.
+ tmp=$TMPDIR; if [ -z $tmp ]; then tmp=/tmp; fi
+ output=$tmp/test_emacs_output.$$
+ test_emacs $1 ${output}
+ result=$(cat ${output})
+ rm -f ${output}
+ fi
+
+ # Restore state after the test.
+ exec 16 27 # Restore stdout and stderr
+ inside_subtest=
+
+ # Report success/failure.
+ if ! test_skip $test_subtest_name
+ then
+ if [ $result == t ]
if [ $result = t ]
to be compatible with POSIX and consistent with rest code.
+ then
+ test_ok_ $test_subtest_name
+ else
+ test_failure_ $test_subtest_name $(eval printf
${result})
This added 'eval' made me investigate further... running
emacsclient --eval '(print (concat a b \t c \n z))'
outputs ab c\nz (tab between 'ab' and 'c', quotes () around
the whole output and newlines as \n (even '\r' is converted)).
If emacs tests run via test_emacs_expect_t wrote their output
to ${output} directly above code could be much cleaner in many
places. Environment variable could be used for the file name.
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: add invisible dot instead of space at the end of notmuch-hello search box
On Tue, 17 Jan 2012 19:55:34 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: This makes `show-trailing-whitespace' happy, i.e. it does not mark the whole search box line as trailing spaces. Since the dot is invisible, this change makes no visible difference for `notmuch-hello'. --- +1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 10:45:06 -0400, David Bremner da...@tethera.net wrote: Here is a very early stage proposal to provide tagging macros for notmuch show mode. Nice idea. Please make it work on regions as well. pgp9jDOp95V8d.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix dependency generation for CLI sources
On Sun, 15 Jan 2012 15:20:23 -0500, Austin Clements amdra...@mit.edu wrote: Previously, the dependency file list was generated before the CLI sources were added to SRCS, so dependency files weren't generated for CLI sources. This moves that code to after the CLI sources are added. --- +1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix dependency generation for compat, test, and util
On Sun, 15 Jan 2012 15:20:42 -0500, Austin Clements amdra...@mit.edu wrote: This adds source files in compat, test, and util to SRCS so that the top-level Makefile.local will generate dependency files for them. --- +1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 4/5] emacs: Use the new JSON reply format.
On Tue, Jan 17, 2012 at 23:54, David Edmondson d...@dme.org wrote: On Tue, 17 Jan 2012 15:53:37 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: +(defun notmuch-parts-filter-by-type (parts type) + Return a list of message parts with the given type + (let (result) + (dolist (part (append parts nil) result) + (if (string= (cdr (assq 'content-type part)) type) + (setq result (append result (list (cdr (assq 'content part))) + result)) I still think that `loop' is easier to read :-) But no objection to this code. I couldn't find the loop construct initially, but after the discussion of common lisp on IRC yesterday I found the cl package and figured out how your example worked. With loop and collect figured out, it is easier to read. +(defun notmuch-mua-insert-part-quoted (part) + (let ((start (point)) + limit) + (insert part) + (setq limit (point)) + (goto-char start) + (while (re-search-forward \\(^\\)[^$] limit 0) + (replace-match nil nil nil 1) + ;; We have added two characters to the quotable region + (setq limit (+ limit 2))) + (set-buffer-modified-p nil))) You could use a marker for the limit, as it would then move along automagically (sorry for not noticing this last time). Aha! Another trick I didn't know about. New patch forthcoming. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 4/5] emacs: Use the new JSON reply format.
Using the new JSON reply format allows emacs to quote HTML parts nicely by using mm-display-part to turn them into displayable text, 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. --- emacs/notmuch-lib.el |8 emacs/notmuch-mua.el | 95 +- 2 files changed, 71 insertions(+), 32 deletions(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 0f856bf..c5c6f91 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -21,6 +21,8 @@ ;; This is an part of an emacs-based interface to the notmuch mail system. +(eval-when-compile (require 'cl)) + (defvar notmuch-command notmuch Command to run the notmuch binary.) @@ -127,6 +129,12 @@ the user hasn't set this variable with the old or new value. (list 'when ( emacs-major-version 23) form)) +(defun notmuch-parts-filter-by-type (parts type) + Return a list of message parts with the given type + (loop for part across parts + if (string= (cdr (assq 'content-type part)) type) + collect (cdr (assq 'content part + ;; Compatibility functions for versions of emacs before emacs 23. ;; ;; Both functions here were copied from emacs 23 with the following copyright: diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index d8ab822..b5c5493 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,49 +72,79 @@ list. (push header message-hidden-headers))) notmuch-mua-hidden-headers)) +(defun notmuch-mua-insert-part-quoted (part) + (let ((start (point)) + limit) +(insert part) +(setq limit (point-marker)) +(goto-char start) +(while (re-search-forward \\(^\\)[^$] (marker-position limit) 0) + (replace-match nil nil nil 1)) +(set-buffer-modified-p nil))) + +(defun notmuch-mua-parse-html-part (part) + (with-temp-buffer +(insert part) +(let ((handle (mm-make-handle (current-buffer) (list text/html))) + (end-of-orig (point-max))) + (mm-display-part handle) + (delete-region (point-min) end-of-orig) + (fill-region (point-min) (point-max)) + (buffer-substring (point-min) (point-max) + (defun notmuch-mua-reply (query-string optional sender reply-all) - (let (headers - body - (args '(reply))) + (let ((args '(reply --format=json)) + reply + body) (if notmuch-show-process-crypto (setq args (append args '(--decrypt (if reply-all (setq args (append args '(--reply-to=all))) (setq args (append args '(--reply-to=sender (setq args (append args (list query-string))) -;; This make assumptions about the output of `notmuch reply', but -;; really only that the headers come first followed by a blank -;; line and then the body. +;; Get the reply object as JSON, and parse it into an elisp object. (with-temp-buffer (apply 'call-process (append (list notmuch-command nil (list t t) nil) args)) (goto-char (point-min)) - (if (re-search-forward ^$ nil t) - (save-excursion - (save-restriction - (narrow-to-region (point-min) (point)) - (goto-char (point-min)) - (setq headers (mail-header-extract) - (forward-line 1) - (setq body (buffer-substring (point) (point-max -;; If sender is non-nil, set the From: header to its value. -(when sender - (mail-header-set 'from sender headers)) -(let - ;; Overlay the composition window on that being used to read - ;; the original message. - ((same-window-regexps '(\\*mail .*))) - (notmuch-mua-mail (mail-header 'to headers) - (mail-header 'subject headers) - (message-headers-to-generate headers t '(to subject -;; insert the message body - but put it in front of the signature -;; if one is present -(goto-char (point-max)) -(if (re-search-backward message-signature-separator nil t) + (setq reply (aref (json-read) 0))) + +;; Start with the prelude, based on the headers of the original message. +(let* ((original (cdr (assq 'original reply))) + (headers (cdr (assq 'headers (assq 'reply reply + (original-headers (cdr (assq 'headers original))) + (body-parts (cdr (assq 'body original))) + (plain-parts (notmuch-parts-filter-by-type body-parts text/plain)) + (html-parts (notmuch-parts-filter-by-type body-parts text/html))) + + ;; If sender is non-nil, set the From: header to its value. + (when sender + (mail-header-set 'from sender headers)) + (let + ;; Overlay the composition window on that being used to read + ;; the original message.
Re: [PATCH v2 4/5] emacs: Use the new JSON reply format.
On Wed, 18 Jan 2012 09:32:34 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca wrote: Using the new JSON reply format allows emacs to quote HTML parts nicely by using mm-display-part to turn them into displayable text, 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. I think that this looks pretty good now. We should get some experience of using it. pgpWwLZtXqqgv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 4/5] emacs: Use the new JSON reply format.
On Wed, Jan 18, 2012 at 09:41, David Edmondson d...@dme.org wrote: I think that this looks pretty good now. We should get some experience of using it. Thanks for the reviews and guidance - I think the patch is in much better shape than when it started. FWIW, I've been using the original w3-based version of the patch for a while now, and the mm-based version since I sent it. It works well with all the emails I've tested it with, but almost all the email I get is HTML-only. I'd like to hear some experiences from people trying it on multipart/alternative messages and others. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6
On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost schno...@schnouki.net wrote: This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test fails (signature verification with signer key unavailable) but this will be hard to fix since the new API does not report the reason why a signature verification fails (other than the human-readable error message). How did you test against multiple versions? Using different machines? If there was a way for configure (or something to pick the version, I would setup the buildbot to test against both, so we don't regress either. Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Make the part content available to the mm-inline* checks.
The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. --- I dropped this on the floor after discussing it in #notmuch, sorry! emacs/notmuch-show.el | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2df8d3b..71309c3 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -330,14 +330,17 @@ current buffer, if possible. (with-temp-buffer (let* ((charset (plist-get part :content-charset)) (handle (mm-make-handle (current-buffer) `(,content-type (charset . ,charset) - (if (and (mm-inlinable-p handle) -(mm-inlined-p handle)) - (let ((content (notmuch-show-get-bodypart-content msg part nth))) - (insert content) - (set-buffer display-buffer) - (mm-display-part handle) - t) - nil) + (insert (notmuch-show-get-bodypart-content msg part nth)) + (when (and (mm-inlinable-p handle) + (mm-inlined-p handle)) + (set-buffer display-buffer) + + ;; Nonsense required to have the new gnus `shr' HTML + ;; display code work. + (let ((gnus-inhibit-images nil)) + (makunbound 'gnus-summary-buffer) ; Blech. + (mm-display-part handle)) + t) (defvar notmuch-show-multipart/alternative-discouraged '( -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the part content available to the mm-inline* checks.
On Wed, 18 Jan 2012 17:33:13 +, David Edmondson d...@dme.org wrote: + ;; Nonsense required to have the new gnus `shr' HTML + ;; display code work. + (let ((gnus-inhibit-images nil)) + (makunbound 'gnus-summary-buffer) ; Blech. + (mm-display-part handle)) + t) Bleugh. Sorry, don't apply this patch. I'll produce a clean one. pgpg9loZRDM97.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: Make the part content available to the mm-inline* checks.
The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. --- Removed the cruft that crept into the previous patch. emacs/notmuch-show.el | 14 ++ 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2df8d3b..f280df2 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -330,14 +330,12 @@ current buffer, if possible. (with-temp-buffer (let* ((charset (plist-get part :content-charset)) (handle (mm-make-handle (current-buffer) `(,content-type (charset . ,charset) - (if (and (mm-inlinable-p handle) -(mm-inlined-p handle)) - (let ((content (notmuch-show-get-bodypart-content msg part nth))) - (insert content) - (set-buffer display-buffer) - (mm-display-part handle) - t) - nil) + (insert (notmuch-show-get-bodypart-content msg part nth)) + (when (and (mm-inlinable-p handle) + (mm-inlined-p handle)) + (set-buffer display-buffer) + (mm-display-part handle) + t) (defvar notmuch-show-multipart/alternative-discouraged '( -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] emacs: use a single history for all searches
On Wed, 18 Jan 2012 08:25:22 +, David Edmondson d...@dme.org wrote: On Tue, 17 Jan 2012 23:34:09 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: There are two ways to do search in Emacs UI: search widget in notmuch-hello buffer and `notmuch-search' function bound to s. Before the change, these search mechanisms used different history lists. The patch makes notmuch-hello search use the same history list as `notmuch-search' function. The test output updates included here should be with the previous patch, shouldn't they? Indeed. Would send v2. -(defun notmuch-search (query optional oldest-first target-thread target-line continuation) - Run \notmuch search\ with the given query string and display results. +(defun notmuch-search (optional query oldest-first target-thread target-line continuation) + Run \notmuch search\ with the given `query' and display results. -The optional parameters are used as follows: +If `query' is nil, it is read interactively from the minibuffer. +Other optional parameters are used as follows: oldest-first: A Boolean controlling the sort order of returned threads target-thread: A thread ID (with the thread: prefix) that will be made current if it appears in the search results. target-line: The line number to move to if the target thread does not appear in the search results. - (interactive (list (notmuch-read-query Notmuch search: ))) + (interactive) + (if (null query) + (setq query (notmuch-read-query Notmuch search: )) +(setq query (notmuch-trim query)) +(let ((history-delete-duplicates t)) + (add-to-history 'notmuch-search-history query))) Should user-typed queries be trimmed? IMO that would not hurt. But we need to do it before it gets added to the history. And that may be tricky. So this patch does trimming only for queries from notmuch-hello search box (as it was before). Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6
On Wed, 18 Jan 2012 12:19:45 -0500, Tom Prince tom.pri...@ualberta.net wrote: How did you test against multiple versions? Using different machines? If there was a way for configure (or something to pick the version, I would setup the buildbot to test against both, so we don't regress either. I currently compile notmuch on Fedora 15 so that I have LIBRARY_PATH=/my/own/path/to/x86_64-linux/lib and CPATH=/my/own/path/to/x86_64-linux/include and gmime 2.4 development files are located in these directories. I'll be hiding gmime 2.4 stuff from these soon in order to build against 2.6 stuff. Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.
Hi David. On Wed, 18 Jan 2012 17:39:31 +, David Edmondson d...@dme.org wrote: The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. Not so long ago I made an opposite change to avoid fetching useless parts (e.g. audio files). Looks like we need a better check here. Can we know from Content-Type if fetching a part body would be useful? Regards, Dmitry --- Removed the cruft that crept into the previous patch. emacs/notmuch-show.el | 14 ++ 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2df8d3b..f280df2 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -330,14 +330,12 @@ current buffer, if possible. (with-temp-buffer (let* ((charset (plist-get part :content-charset)) (handle (mm-make-handle (current-buffer) `(,content-type (charset . ,charset) - (if (and (mm-inlinable-p handle) - (mm-inlined-p handle)) - (let ((content (notmuch-show-get-bodypart-content msg part nth))) - (insert content) - (set-buffer display-buffer) - (mm-display-part handle) - t) - nil) + (insert (notmuch-show-get-bodypart-content msg part nth)) + (when (and (mm-inlinable-p handle) +(mm-inlined-p handle)) + (set-buffer display-buffer) + (mm-display-part handle) + t) (defvar notmuch-show-multipart/alternative-discouraged '( -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] emacs: use a single history for all searches
On Wed, 18 Jan 2012 21:57:27 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: The test output updates included here should be with the previous patch, shouldn't they? Indeed. Would send v2. That's not necessary for me. Should user-typed queries be trimmed? IMO that would not hurt. But we need to do it before it gets added to the history. And that may be tricky. So this patch does trimming only for queries from notmuch-hello search box (as it was before). Okay. pgpNUcrtWdDXK.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.
On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 18 Jan 2012 17:39:31 +, David Edmondson d...@dme.org wrote: The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. Not so long ago I made an opposite change to avoid fetching useless parts (e.g. audio files). Looks like we need a better check here. Can we know from Content-Type if fetching a part body would be useful? What if `notmuch-show-insert-part-*/*' consulted a list of content-type regexps to attempt to inline? That would allow a sane default ((image/* text/*) perhaps), but also allow more to be added to that list (or some to be removed), either by code that detected the (in)ability to render it or the user. pgpkKQiNlrsdD.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
Quoth David Bremner on Jan 18 at 10:45 am: Hi All; Here is a very early stage proposal to provide tagging macros for notmuch show mode. The idea is that user defines a mapping from single key to a sequence of tagging operations. It might be nice if there as some kind of pop-up menu, or at least a prompt, but I didn't do that so far. The advantage of this rather than just writing lots of little lambdas is that it combines adding and deleting, and it could be done via customize. As provided, the code should just paste into .emacs, and with a little editing into notmuch-show.el. What about simply providing an API that takes a bunch of tag operations and applies them to the current thread/message/region? Maybe even the notmuch-show-add-or-del-tags that you have below (probably spruced up a bit). I feel like the type of people who are likely to use tag macros would also have the know-how to add a simple key binding of their own, assuming it *were* simple. Such an API would probably clean up some of the tagging code in notmuch-show, too. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4] emacs: logically group def{custom,face}s
Quoth Pieter Praet on Jan 18 at 11:00 am: On Mon, 16 Jan 2012 14:16:22 -0500, Austin Clements amdra...@mit.edu wrote: LGTM. Quoth Pieter Praet on Jan 16 at 11:38 am: - Add `notmuch-send' to the `message' group, as per Austin's recommendation [1]. This is actually the reverse of what I was suggesting (though is also reasonable). Since notmuch uses message-mode, I was saying that the notmuch group (or the notmuch-send group) should link to the message group. That way, if you customize-group notmuch, you get all of the options that affect notmuch, even those that aren't strictly notmuch variables. Sorry, failed to mention; I tried that, but the additional :link '(custom-group-link :tag Message message) didn't seem all that useful compared to (or combined with) adding `message' as parent group to `notmuch-send': #+begin_example Parent groups: Message Notmuch /- Notmuch Send group: Sending messages from Notmuch.\ State: something in this group has been changed outside customize. #+end_example vs. #+begin_example Parent groups: Message Notmuch /- Notmuch Send group: Sending messages from Notmuch.\ State: something in this group has been changed outside customize. See also Message. #+end_example ... so I ripped it out again. Should I add it back? Hmm. You're right that the :link doesn't do much. One other possibility to consider is (custom-add-to-group 'notmuch-show 'message 'custom-group) or even (custom-add-to-group 'notmuch 'message 'custom-group) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 10:45:06 -0400, David Bremner da...@tethera.net wrote: The advantage of this rather than just writing lots of little lambdas is that it combines adding and deleting, and it could be done via customize. Is all of this really easier than just adding the following to your .emacs?: (define-key notmuch-search-mode-map o (lambda () (interactive) (notmuch-show-add-tag notmuch::patch) (notmuch-show-add-tag notmuch::obsolete) (notmuch-show-remove-tag notmuch::needs-review))) That seems really simple to me, and doesn't require us to support a bunch of code to do complicated customization stuff. Rather than have protracted conversations about key bindings or continue to make more complicated configuration setups, I would like to push the idea that we support a bunch of nice simple functions to do common, useful operations (like tagging and navigation), and let users build macros as they see fit. I think this is a lot more flexible, and takes a lot of the maintenance burden off of us. I've been wanting to put together a wiki page that lists all the useful functions and has examples of how to put them together into useful functions. jamie. pgp6QJmcNGqJH.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 3/3] search: Support automatic tag exclusions
On Wed, 18 Jan 2012 09:52:52 +, David Edmondson d...@dme.org wrote: I agree that as long as no keys are pre-bound it will make little difference. That just transfers the discussion to the thread about adding the bindings, which seems silly. I think that's ok. The tag exclusion is in, which is great. The next question, of whether we should setup excludes by default, is intimately related to whether or not we support key bindings to add those tags. So I think it's fine to transfer the rest of this discussion to that thread. jamie. pgpK5K6CYOuF2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end
On Wed, 18 Jan 2012 08:56:26 +, David Edmondson d...@dme.org wrote: I'm used to the cursor going to the bottom of the thread to let me know that I reached the end, then I hit 'space' and move on to the next thread. Will that behaviour be retained with this patch? (Well, including your other patch which seemed to set `pop-at-end'.) This doesn't change the default behavior of the 'n' key, if that's what you're asking, so the behavior you're describing should work the same. jamie. pgpd82IFDUBLR.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.
On Wed, 18 Jan 2012 18:30:36 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 18 Jan 2012 17:39:31 +, David Edmondson d...@dme.org wrote: The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. Not so long ago I made an opposite change to avoid fetching useless parts (e.g. audio files). Looks like we need a better check here. Can we know from Content-Type if fetching a part body would be useful? What if `notmuch-show-insert-part-*/*' consulted a list of content-type regexps to attempt to inline? That would allow a sane default ((image/* text/*) perhaps), but also allow more to be added to that list (or some to be removed), either by code that detected the (in)ability to render it or the user. Perhaps there is such a list in mm already? Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 13:33:04 -0500, Austin Clements amdra...@mit.edu wrote: Quoth David Bremner on Jan 18 at 10:45 am: What about simply providing an API that takes a bunch of tag operations and applies them to the current thread/message/region? My main motivation here is (as you can probably see from the example) dealing with patches, and in that setting, tagging the whole thread is is almost never what you want. That aside, thread tagging is already there in search view, and I guess could be done by selecting the whole thread and tagging that region. I haven't really looked at how to apply tags to regions in notmuch-show-mode. Is there code around that does that? Or more generally iterate over messages in a region? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
Quoth David Bremner on Jan 18 at 3:03 pm: On Wed, 18 Jan 2012 13:33:04 -0500, Austin Clements amdra...@mit.edu wrote: Quoth David Bremner on Jan 18 at 10:45 am: What about simply providing an API that takes a bunch of tag operations and applies them to the current thread/message/region? My main motivation here is (as you can probably see from the example) dealing with patches, and in that setting, tagging the whole thread is is almost never what you want. That aside, thread tagging is already there in search view, and I guess could be done by selecting the whole thread and tagging that region. I haven't really looked at how to apply tags to regions in notmuch-show-mode. Is there code around that does that? Or more generally iterate over messages in a region? Sorry, that was all a bit of a red herring in my email. The high-level point I was trying to make is really what Jamie said. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] Make buttons for attachments allow viewing as well as saving
Quoth Mark Walters on Jan 18 at 10:46 am: +(defun notmuch-show-view-part (message-id nth optional filename content-type ) + (notmuch-with-temp-part-buffer message-id nth +;; set mm-inlined-types to nil to force an external viewer +(let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + ;; We override mm-save-part as notmuch-show-save-part is better + ;; since it offers the filename + (flet ((mm-save-part (rest args) (ignore))) + (or (mm-display-part handle) + (notmuch-show-save-part message-id nth filename content-type)) Is that a reasonable solution? It's *probably* safe to depend on the result of mm-display-part, but you can avoid the question altogether by simply calling notmuch-show-save-part from your flet mm-save-part. E.g., (flet ((mm-save-part (rest args) (notmuch-show-save-part message-id nth filename content-type))) (mm-display-part handle)) Unfortunately that does not work since mm-display-part has a local variable filename. I could copy the variables to some notmuch prefixed variables but maybe there is some obvious quoting to avoid the problem? (I can't easily check now as the gnu site is closed for the day.) Arrrg, dynamic scoping. Well, you can ;; Lexically bind everything we need in mm-save-part to prevent ;; potential dynamic shadowing. (lexical-let ((message-id message-id) (nth nth) (filename filename) (content-type content-type)) (flet ((mm-save-part (rest args) (notmuch-show-save-part message-id nth filename content-type))) (mm-display-part handle))) Or you could just, y'know, do what were doing. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 15:03:52 -0400, David Bremner da...@tethera.net wrote:
My main motivation here is (as you can probably see from the example)
dealing with patches, and in that setting, tagging the whole thread is
is almost never what you want.
The example I sent was about tagging individual message, not threads.
That aside, thread tagging is already there in search view, and I guess
could be done by selecting the whole thread and tagging that region.
Thread tagging would be supported in show mode with the recent
notmuch-show-{add,remove}-tag-thread patches I sent:
id:1326823531-14549-1-git-send-email-jroll...@finestructure.net
I haven't really looked at how to apply tags to regions in
notmuch-show-mode. Is there code around that does that? Or more
generally iterate over messages in a region?
I don't think the show mode tagging functions support regions at the
moment, but I think extending them to do that would be a good idea.
jamie.
pgpvHPefK2t2q.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.
Quoth Dmitry Kurochkin on Jan 18 at 11:00 pm: On Wed, 18 Jan 2012 18:30:36 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 18 Jan 2012 17:39:31 +, David Edmondson d...@dme.org wrote: The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. Not so long ago I made an opposite change to avoid fetching useless parts (e.g. audio files). Looks like we need a better check here. Can we know from Content-Type if fetching a part body would be useful? What if `notmuch-show-insert-part-*/*' consulted a list of content-type regexps to attempt to inline? That would allow a sane default ((image/* text/*) perhaps), but also allow more to be added to that list (or some to be removed), either by code that detected the (in)ability to render it or the user. Perhaps there is such a list in mm already? Shouldn't we only be doing this for parts with inline (or not attachment) content-disposition? That's cheap to check. Or do we actually want things like image attachments to get inlined, despite their disposition? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.
On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Dmitry Kurochkin on Jan 18 at 11:00 pm: On Wed, 18 Jan 2012 18:30:36 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 18 Jan 2012 17:39:31 +, David Edmondson d...@dme.org wrote: The `mm-inlinable-p' and `mm-inlined-p' functions work better if they have access to the data of the relevant part, so load that content before calling either function. This fixes the display of attached image/jpeg parts, for example. Not so long ago I made an opposite change to avoid fetching useless parts (e.g. audio files). Looks like we need a better check here. Can we know from Content-Type if fetching a part body would be useful? What if `notmuch-show-insert-part-*/*' consulted a list of content-type regexps to attempt to inline? That would allow a sane default ((image/* text/*) perhaps), but also allow more to be added to that list (or some to be removed), either by code that detected the (in)ability to render it or the user. Perhaps there is such a list in mm already? Shouldn't we only be doing this for parts with inline (or not attachment) content-disposition? That's cheap to check. Or do we actually want things like image attachments to get inlined, despite their disposition? It may be good to have this behavior configurable. I would like Emacs to display all part types that it can, independent from content-disposition. Anyway, this is a separate issue. In any case we want to fetch part body only if it is useful. Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/3] emacs: notmuch-hello search cleanup
Changes in v2 since v1: * expected results changes for tests moved from patch 2 to 1 where it belong Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 1/3] emacs: bind s to `notmuch-search' in notmuch-hello buffer
Before the change, s in notmuch-hello buffer would jump to the search box. The patch changes the binding to `notmuch-search' which is consistent with all other notmuch buffers. --- emacs/notmuch-hello.el | 19 ++- test/emacs.expected-output/notmuch-hello |2 +- .../notmuch-hello-no-saved-searches|2 +- .../emacs.expected-output/notmuch-hello-with-empty |2 +- 4 files changed, 9 insertions(+), 16 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 02017ce..08fcd22 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -29,9 +29,6 @@ (declare-function notmuch-search notmuch (query optional oldest-first target-thread target-line continuation)) (declare-function notmuch-poll notmuch ()) -(defvar notmuch-hello-search-bar-marker nil - The position of the search bar within the notmuch-hello buffer.) - (defcustom notmuch-recent-searches-max 10 The number of recent searches to store and display. :type 'integer @@ -321,11 +318,6 @@ should be. Returns a cons cell `(tags-per-line width)'. (widget-insert \n)) found-target-pos)) -(defun notmuch-hello-goto-search () - Put point inside the `search' widget. - (interactive) - (goto-char notmuch-hello-search-bar-marker)) - (defimage notmuch-hello-logo ((:type png :file notmuch-logo.png))) (defun notmuch-hello-search-continuation() @@ -355,7 +347,7 @@ should be. Returns a cons cell `(tags-per-line width)'. (define-key map G 'notmuch-hello-poll-and-update) (define-key map (kbd C-tab) 'widget-backward) (define-key map m 'notmuch-mua-new-mail) -(define-key map s 'notmuch-hello-goto-search) +(define-key map s 'notmuch-search) map) Keymap for \notmuch hello\ buffers.) (fset 'notmuch-hello-mode-map notmuch-hello-mode-map) @@ -468,7 +460,8 @@ Complete list of currently available key bindings: (widget-insert messages.\n)) (let ((found-target-pos nil) - (final-target-pos nil)) + (final-target-pos nil) + (search-bar-pos)) (let* ((saved-alist ;; Filter out empty saved searches if required. (if notmuch-show-empty-saved-searches @@ -500,7 +493,7 @@ Complete list of currently available key bindings: (indent-rigidly start (point) notmuch-hello-indent))) (widget-insert \nSearch: ) - (setq notmuch-hello-search-bar-marker (point-marker)) + (setq search-bar-pos (point-marker)) (widget-create 'editable-field ;; Leave some space at the start and end of the ;; search boxes. @@ -589,7 +582,7 @@ Complete list of currently available key bindings: (when notmuch-saved-searches (widget-insert Edit saved searches with the `edit' button.\n)) (widget-insert Hit RET or click on a saved search or tag name to view matching threads.\n) - (widget-insert `=' refreshes this screen. `s' jumps to the search box. `q' to quit.\n) + (widget-insert `=' refreshes this screen. `s' to search messages. `q' to quit.\n) (let ((fill-column (- (window-width) notmuch-hello-indent))) (center-region start (point @@ -601,7 +594,7 @@ Complete list of currently available key bindings: (widget-forward 1))) (unless (widget-at) - (notmuch-hello-goto-search + (goto-char search-bar-pos (run-hooks 'notmuch-hello-refresh-hook)) diff --git a/test/emacs.expected-output/notmuch-hello b/test/emacs.expected-output/notmuch-hello index de57de2..da47a6b 100644 --- a/test/emacs.expected-output/notmuch-hello +++ b/test/emacs.expected-output/notmuch-hello @@ -11,4 +11,4 @@ Search: Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. -`=' refreshes this screen. `s' jumps to the search box. `q' to quit. + `=' refreshes this screen. `s' to search messages. `q' to quit. diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches b/test/emacs.expected-output/notmuch-hello-no-saved-searches index f1fc4d6..202d7d2 100644 --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches @@ -7,4 +7,4 @@ Search: Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. -`=' refreshes this screen. `s' jumps to the search box. `q' to quit. + `=' refreshes this screen. `s' to search messages. `q' to quit. diff --git a/test/emacs.expected-output/notmuch-hello-with-empty b/test/emacs.expected-output/notmuch-hello-with-empty index dd8728b..d810b51 100644 --- a/test/emacs.expected-output/notmuch-hello-with-empty +++
[PATCH v2 3/3] emacs: bind s to `notmuch-hello-search' in notmuch-hello buffer
`notmuch-hello-search' uses `notmuch-search' function but refreshes notmuch-hello buffer when the search buffer is closed. --- emacs/notmuch-hello.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index cb36977..e908659 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -163,7 +163,8 @@ International Bureau of Weights and Measures. (format %s%03d notmuch-hello-thousands-separator elem)) (cdr result) -(defun notmuch-hello-search (search) +(defun notmuch-hello-search (optional search) + (interactive) (notmuch-search search notmuch-search-oldest-first nil nil #'notmuch-hello-search-continuation)) @@ -330,7 +331,7 @@ should be. Returns a cons cell `(tags-per-line width)'. (define-key map G 'notmuch-hello-poll-and-update) (define-key map (kbd C-tab) 'widget-backward) (define-key map m 'notmuch-mua-new-mail) -(define-key map s 'notmuch-search) +(define-key map s 'notmuch-hello-search) map) Keymap for \notmuch hello\ buffers.) (fset 'notmuch-hello-mode-map notmuch-hello-mode-map) -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 2/3] emacs: use a single history for all searches
There are two ways to do search in Emacs UI: search widget in notmuch-hello buffer and `notmuch-search' function bound to s. Before the change, these search mechanisms used different history lists. The patch makes notmuch-hello search use the same history list as `notmuch-search' function. --- emacs/notmuch-hello.el | 49 ++- emacs/notmuch-lib.el |9 emacs/notmuch.el | 19 - 3 files changed, 37 insertions(+), 40 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 08fcd22..cb36977 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -29,8 +29,8 @@ (declare-function notmuch-search notmuch (query optional oldest-first target-thread target-line continuation)) (declare-function notmuch-poll notmuch ()) -(defcustom notmuch-recent-searches-max 10 - The number of recent searches to store and display. +(defcustom notmuch-hello-recent-searches-max 10 + The number of recent searches to display. :type 'integer :group 'notmuch) @@ -151,16 +151,6 @@ International Bureau of Weights and Measures. (defvar notmuch-hello-url http://notmuchmail.org; The `notmuch' web site.) -(defvar notmuch-hello-recent-searches nil) - -(defun notmuch-hello-remember-search (search) - (setq notmuch-hello-recent-searches - (delete search notmuch-hello-recent-searches)) - (push search notmuch-hello-recent-searches) - (if ( (length notmuch-hello-recent-searches) -notmuch-recent-searches-max) - (setq notmuch-hello-recent-searches (butlast notmuch-hello-recent-searches - (defun notmuch-hello-nice-number (n) (let (result) (while ( n 0) @@ -173,16 +163,9 @@ International Bureau of Weights and Measures. (format %s%03d notmuch-hello-thousands-separator elem)) (cdr result) -(defun notmuch-hello-trim (search) - Trim whitespace. - (if (string-match ^[[:space:]]*\\(.*[^[:space:]]\\)[[:space:]]*$ search) - (match-string 1 search) -search)) - (defun notmuch-hello-search (search) - (let ((search (notmuch-hello-trim search))) -(notmuch-hello-remember-search search) -(notmuch-search search notmuch-search-oldest-first nil nil #'notmuch-hello-search-continuation))) + (notmuch-search search notmuch-search-oldest-first nil nil + #'notmuch-hello-search-continuation)) (defun notmuch-hello-add-saved-search (widget) (interactive) @@ -461,7 +444,7 @@ Complete list of currently available key bindings: (let ((found-target-pos nil) (final-target-pos nil) - (search-bar-pos)) + (default-pos)) (let* ((saved-alist ;; Filter out empty saved searches if required. (if notmuch-show-empty-saved-searches @@ -493,7 +476,7 @@ Complete list of currently available key bindings: (indent-rigidly start (point) notmuch-hello-indent))) (widget-insert \nSearch: ) - (setq search-bar-pos (point-marker)) + (setq default-pos (point-marker)) (widget-create 'editable-field ;; Leave some space at the start and end of the ;; search boxes. @@ -507,18 +490,18 @@ Complete list of currently available key bindings: (put-text-property (1- (point)) (point) 'invisible t) (widget-insert \n) - (when notmuch-hello-recent-searches + (when notmuch-search-history (widget-insert \nRecent searches: ) (widget-create 'push-button :notify (lambda (rest ignore) - (setq notmuch-hello-recent-searches nil) + (setq notmuch-search-history nil) (notmuch-hello-update)) clear) (widget-insert \n\n) - (let ((start (point)) - (nth 0)) - (mapc (lambda (search) - (let ((widget-symbol (intern (format notmuch-hello-search-%d nth + (let ((start (point))) + (loop for i from 1 to notmuch-hello-recent-searches-max + for search in notmuch-search-history do + (let ((widget-symbol (intern (format notmuch-hello-search-%d i (set widget-symbol (widget-create 'editable-field ;; Don't let the search boxes be @@ -545,9 +528,7 @@ Complete list of currently available key bindings: (notmuch-hello-add-saved-search widget)) :notmuch-saved-search-widget widget-symbol save)) - (widget-insert \n) - (setq nth (1+ nth))) - notmuch-hello-recent-searches) + (widget-insert \n)) (indent-rigidly start (point) notmuch-hello-indent)))
[PATCH 0/3] Second step of 'show' rewrite
This adds support for self-recursive message formatters, while maintaining backwards compatibility with old style formatters. After this, each format can be converted to the new style individually and, once they're all converted, a bunch of code can be deleted. These three patches are independent and can be pushed in any order. I put them in a series because pushing them before any formatter rewrites will simplify dependencies between the individual formatter rewrites. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] mime node: Record depth-first part numbers
This makes the part numbers readily accessible to formatters.
Hierarchical part numbering would be a more natural and efficient fit
for MIME and may be the way to go in the future, but depth-first
numbering maintains compatibility with what we currently do.
---
mime-node.c | 33 -
notmuch-client.h | 11 +++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index d26bb44..30b542f 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t
*message,
root-nchildren = 1;
root-ctx = mctx;
+root-part_num = 0;
+root-next_child = 0;
+root-next_part_num = 1;
+
*root_out = root;
return NOTMUCH_STATUS_SUCCESS;
@@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent, GMimeObject
*part)
talloc_free (node);
return NULL;
}
+node-parent = parent;
+node-part_num = node-next_part_num = -1;
/* Deal with the different types of parts */
if (GMIME_IS_PART (part)) {
@@ -217,6 +223,7 @@ mime_node_t *
mime_node_child (const mime_node_t *parent, int child)
{
GMimeObject *sub;
+mime_node_t *node;
if (!parent || child 0 || child = parent-nchildren)
return NULL;
@@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)
INTERNAL_ERROR (Unexpected GMimeObject type: %s,
g_type_name (G_OBJECT_TYPE (parent-part)));
}
-return _mime_node_create (parent, sub);
+node = _mime_node_create (parent, sub);
+
+if (child == parent-next_child parent-next_part_num != -1) {
+ /* We're traversing in depth-first order. Record the child's
+* depth-first numbering. */
+ node-part_num = parent-next_part_num;
+ node-next_part_num = node-part_num + 1;
+
+ /* Drop the const qualifier because these are internal fields
+* whose mutability doesn't affect the interface. */
+ ((mime_node_t*)parent)-next_child++;
+ ((mime_node_t*)parent)-next_part_num = -1;
+
+ if (node-nchildren == 0) {
+ /* We've reached a leaf, so find the parent that has more
+* children and set it up to number its next child. */
+ const mime_node_t *it = node;
+ while (it it-next_child == it-nchildren)
+ it = it-parent;
+ if (it)
+ ((mime_node_t*)it)-next_part_num = node-part_num + 1;
+ }
+}
+
+return node;
}
static mime_node_t *
diff --git a/notmuch-client.h b/notmuch-client.h
index 62ede28..b3dcb6b 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -281,6 +281,13 @@ typedef struct mime_node {
/* The number of children of this part. */
int nchildren;
+/* The parent of this node or NULL if this is the root node. */
+const struct mime_node *parent;
+
+/* The depth-first part number of this child if the MIME tree is
+ * being traversed in depth-first order, or -1 otherwise. */
+int part_num;
+
/* True if decryption of this part was attempted. */
notmuch_bool_t decrypt_attempted;
/* True if decryption of this part's child succeeded. In this
@@ -302,6 +309,10 @@ typedef struct mime_node {
/* Internal: For successfully decrypted multipart parts, the
* decrypted part to substitute for the second child. */
GMimeObject *decrypted_child;
+
+/* Internal: The next child for depth-first traversal and the part
+ * number to assign it (or -1 if unknown). */
+int next_child, next_part_num;
} mime_node_t;
/* Construct a new MIME node pointing to the root message part of
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] show: Use consistent header ordering in the text format
Previously, top-level message headers were printed as Subject, From,
To, Date, while embedded message headers were printed From, To,
Subject, Date. This makes both cases use the former order and updates
the tests accordingly.
Strangely, the raw format also uses this function, so this also fixes
the two raw format tests affected by this change.
---
notmuch-show.c |2 +-
test/multipart | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..ecadfa8 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -360,6 +360,7 @@ format_headers_message_part_text (GMimeMessage *message)
InternetAddressList *recipients;
const char *recipients_string;
+printf (Subject: %s\n, g_mime_message_get_subject (message));
printf (From: %s\n, g_mime_message_get_sender (message));
recipients = g_mime_message_get_recipients (message,
GMIME_RECIPIENT_TYPE_TO);
recipients_string = internet_address_list_to_string (recipients, 0);
@@ -371,7 +372,6 @@ format_headers_message_part_text (GMimeMessage *message)
if (recipients_string)
printf (Cc: %s\n,
recipients_string);
-printf (Subject: %s\n, g_mime_message_get_subject (message));
printf (Date: %s\n, g_mime_message_get_date_as_string (message));
}
diff --git a/test/multipart b/test/multipart
index f83526b..2dd73f5 100755
--- a/test/multipart
+++ b/test/multipart
@@ -121,9 +121,9 @@ Date: Fri, 05 Jan 2001 15:43:57 +
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
header{
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
header}
body{
@@ -162,9 +162,9 @@ cat EOF EXPECTED
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
header{
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
header}
body{
@@ -200,9 +200,9 @@ cat EOF EXPECTED
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
header{
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
header}
body{
@@ -233,9 +233,9 @@ notmuch show --format=text --part=3
'id:87liy5ap00@yoom.home.cworth.org' OU
cat EOF EXPECTED
part{ ID: 3, Content-type: message/rfc822
header{
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
header}
body{
@@ -452,9 +452,9 @@ notmuch show --format=raw --part=1
'id:87liy5ap00@yoom.home.cworth.org' OUT
# output should *not* include newline
echo OUTPUT
cat EOF EXPECTED
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
pThis is an embedded message, with a multipart/alternative part./p
@@ -476,9 +476,9 @@ test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest --format=raw --part=2, multipart/mixed
notmuch show --format=raw --part=2 'id:87liy5ap00@yoom.home.cworth.org'
OUTPUT
cat EOF EXPECTED
+Subject: html message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +
pThis is an embedded message, with a multipart/alternative part./p
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/3] show: Introduce mime_node formatter callback
This callback is the gateway to the new mime_node_t-based formatters.
This maintains backwards compatibility so the formatters can be
transitioned one at a time. Once all formatters are converted, the
formatter structure can be reduced to only message_set_{start,sep,end}
and part, most of show_message can be deleted, and all of
show-message.c can be deleted.
---
notmuch-client.h |6 ++
notmuch-reply.c |2 +-
notmuch-show.c | 22 ++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index b3dcb6b..3ccdfad 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -54,8 +54,14 @@
#define STRINGIFY(s) STRINGIFY_(s)
#define STRINGIFY_(s) #s
+struct mime_node;
+struct notmuch_show_params;
+
typedef struct notmuch_show_format {
const char *message_set_start;
+void (*part) (const void *ctx,
+ struct mime_node *node, int indent,
+ struct notmuch_show_params *params);
const char *message_start;
void (*message) (const void *ctx,
notmuch_message_t *message,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 0f682db..9a224e2 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -31,7 +31,7 @@ static void
reply_part_content (GMimeObject *part);
static const notmuch_show_format_t format_reply = {
-,
+, NULL,
, NULL,
, NULL, reply_headers_message_part, \n,
,
diff --git a/notmuch-show.c b/notmuch-show.c
index ecadfa8..46eef44 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -42,7 +42,7 @@ static void
format_part_end_text (GMimeObject *part);
static const notmuch_show_format_t format_text = {
-,
+, NULL,
\fmessage{ , format_message_text,
\fheader{\n, format_headers_text,
format_headers_message_part_text, \fheader}\n,
\fbody{\n,
@@ -85,7 +85,7 @@ static void
format_part_end_json (GMimeObject *part);
static const notmuch_show_format_t format_json = {
-[,
+[, NULL,
{, format_message_json,
\headers\: {, format_headers_json,
format_headers_message_part_json, },
, \body\: [,
@@ -106,7 +106,7 @@ format_message_mbox (const void *ctx,
unused (int indent));
static const notmuch_show_format_t format_mbox = {
-,
+, NULL,
, format_message_mbox,
, NULL, NULL, ,
,
@@ -125,7 +125,7 @@ static void
format_part_content_raw (GMimeObject *part);
static const notmuch_show_format_t format_raw = {
-,
+, NULL,
, NULL,
, NULL, format_headers_message_part_text, \n,
,
@@ -762,6 +762,20 @@ show_message (void *ctx,
int indent,
notmuch_show_params_t *params)
{
+if (format-part) {
+ void *local = talloc_new (ctx);
+ mime_node_t *root, *part;
+
+ if (mime_node_open (local, message, params-cryptoctx, params-decrypt,
+ root) != NOTMUCH_STATUS_SUCCESS)
+ return;
+ part = mime_node_seek_dfs (root, params-part 0 ? 0 : params-part);
+ if (part)
+ format-part (local, part, indent, params);
+ talloc_free (local);
+ return;
+}
+
if (params-part = 0) {
fputs (format-message_start, stdout);
if (format-message)
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/3] Second step of 'show' rewrite
Hi Austin. On Wed, 18 Jan 2012 15:28:24 -0500, Austin Clements amdra...@mit.edu wrote: This adds support for self-recursive message formatters, while maintaining backwards compatibility with old style formatters. After this, each format can be converted to the new style individually and, once they're all converted, a bunch of code can be deleted. These three patches are independent and can be pushed in any order. I put them in a series because pushing them before any formatter rewrites will simplify dependencies between the individual formatter rewrites. Thank you for the patches. Sorry, I did not manage to review your previous RFC series [1] yet (but it is on my TODO list). These patches are partially the same as in the RFC series. I suppose I should start with reviewing these new series first, right? Does it still makes sense to review the RFC series after that? Regards, Dmitry [1] id:1326332973-30225-1-git-send-email-amdra...@mit.edu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/3] Second step of 'show' rewrite
Quoth Dmitry Kurochkin on Jan 19 at 12:35 am: Hi Austin. On Wed, 18 Jan 2012 15:28:24 -0500, Austin Clements amdra...@mit.edu wrote: This adds support for self-recursive message formatters, while maintaining backwards compatibility with old style formatters. After this, each format can be converted to the new style individually and, once they're all converted, a bunch of code can be deleted. These three patches are independent and can be pushed in any order. I put them in a series because pushing them before any formatter rewrites will simplify dependencies between the individual formatter rewrites. Thank you for the patches. Sorry, I did not manage to review your previous RFC series [1] yet (but it is on my TODO list). These patches are partially the same as in the RFC series. I suppose I should start with reviewing these new series first, right? Does it still makes sense to review the RFC series after that? No worries. Reviewing these first would be best. These patches are very similar to the first few in the RFC series (maybe identical? I forget), so there's no point in reviewing those after these. However, the RFC series goes on to restructure the text formatter and I would love to have someone skim over those before I send that part out for real. Regards, Dmitry [1] id:1326332973-30225-1-git-send-email-amdra...@mit.edu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] config: Better formatting for search section comment
Since auto_exclude_tags is long and its description is multi-line,
start the description on the next line and indent it consistently.
---
notmuch-config.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/notmuch-config.c b/notmuch-config.c
index 3d4d5b9..8dcfe86 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -89,9 +89,10 @@ static const char search_config_comment[] =
\n
The following option is supported here:\n
\n
-\tauto_exclude_tags A ;-separated list of tags that will be\n
-\t excluded from search results by default. Using an excluded tag\n
-\t in a query will override that exclusion.\n;
+\tauto_exclude_tags\n
+\t\tA ;-separated list of tags that will be excluded from\n
+\t\tsearch results by default. Using an excluded tag in a\n
+\t\tquery will override that exclusion.\n;
struct _notmuch_config {
char *filename;
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] News for tag exclusion
--- NEWS | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index 1e561a9..6afa912 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,13 @@ Reply to sender to all. The feature is available through the new command line option --reply-to=(all|sender). +Tag exclusion + + Tags can be automatically excluded from search results unless they + appear explicitly in a query. By default, notmuch excludes the tags + deleted and spam. This can be changed using the new config setting + search.auto_exclude_tags. + Emacs Interface --- @@ -21,6 +28,14 @@ Reply to sender and search modes, 'r' has been bound to reply to sender, replacing reply to all, which now has key binding 'R'. +Library changes +--- + +New functions + + notmuch_query_add_tag_exclude supports the new tag exclusion + feature. + Notmuch 0.11 (2012-01-13) = -- 1.7.7.3 ___ 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
Re: [PATCH 1/3] mime node: Record depth-first part numbers
On Wed, 18 Jan 2012 15:28:25 -0500, Austin Clements amdra...@mit.edu wrote:
This makes the part numbers readily accessible to formatters.
Hierarchical part numbering would be a more natural and efficient fit
for MIME and may be the way to go in the future, but depth-first
numbering maintains compatibility with what we currently do.
Hi, please find a few things to consider below. If you disagree after
considering, it's quite all right, as they're largely style matters. :)
BR,
Jani.
---
mime-node.c | 33 -
notmuch-client.h | 11 +++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index d26bb44..30b542f 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t
*message,
root-nchildren = 1;
root-ctx = mctx;
+root-part_num = 0;
+root-next_child = 0;
+root-next_part_num = 1;
+
*root_out = root;
return NOTMUCH_STATUS_SUCCESS;
@@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent, GMimeObject
*part)
talloc_free (node);
return NULL;
}
+node-parent = parent;
+node-part_num = node-next_part_num = -1;
/* Deal with the different types of parts */
if (GMIME_IS_PART (part)) {
@@ -217,6 +223,7 @@ mime_node_t *
mime_node_child (const mime_node_t *parent, int child)
{
GMimeObject *sub;
+mime_node_t *node;
if (!parent || child 0 || child = parent-nchildren)
return NULL;
@@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)
INTERNAL_ERROR (Unexpected GMimeObject type: %s,
g_type_name (G_OBJECT_TYPE (parent-part)));
}
-return _mime_node_create (parent, sub);
+node = _mime_node_create (parent, sub);
+
+if (child == parent-next_child parent-next_part_num != -1) {
+ /* We're traversing in depth-first order. Record the child's
+ * depth-first numbering. */
+ node-part_num = parent-next_part_num;
+ node-next_part_num = node-part_num + 1;
+
+ /* Drop the const qualifier because these are internal fields
+ * whose mutability doesn't affect the interface. */
FWIW, I'm not a big fan of casting away const. Either it is const, or it
isn't. Not very many places would be affected if you dropped the const
qualifier from the related interface(s) altogether, and things would
look cleaner here. But I suppose this is a matter of taste.
+ ((mime_node_t*)parent)-next_child++;
+ ((mime_node_t*)parent)-next_part_num = -1;
+
+ if (node-nchildren == 0) {
+ /* We've reached a leaf, so find the parent that has more
+ * children and set it up to number its next child. */
+ const mime_node_t *it = node;
+ while (it it-next_child == it-nchildren)
+ it = it-parent;
+ if (it)
+ ((mime_node_t*)it)-next_part_num = node-part_num + 1;
+ }
+}
Following the constness around made me wonder why the above if block
isn't within _mime_node_create(). It does have a feel of initialization
related to creation in it. (You'd have to pass more info to it though.)
+
+return node;
}
static mime_node_t *
diff --git a/notmuch-client.h b/notmuch-client.h
index 62ede28..b3dcb6b 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -281,6 +281,13 @@ typedef struct mime_node {
/* The number of children of this part. */
int nchildren;
+/* The parent of this node or NULL if this is the root node. */
+const struct mime_node *parent;
+
+/* The depth-first part number of this child if the MIME tree is
+ * being traversed in depth-first order, or -1 otherwise. */
+int part_num;
+
/* True if decryption of this part was attempted. */
notmuch_bool_t decrypt_attempted;
/* True if decryption of this part's child succeeded. In this
@@ -302,6 +309,10 @@ typedef struct mime_node {
/* Internal: For successfully decrypted multipart parts, the
* decrypted part to substitute for the second child. */
GMimeObject *decrypted_child;
+
+/* Internal: The next child for depth-first traversal and the part
+ * number to assign it (or -1 if unknown). */
+int next_child, next_part_num;
A matter of taste again, but I wouldn't use int foo, bar in struct
declarations.
} mime_node_t;
/* Construct a new MIME node pointing to the root message part of
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] config: Better formatting for search section comment
On Wed, 18 Jan 2012 15:56:45 -0500, Austin Clements amdra...@mit.edu wrote: Since auto_exclude_tags is long and its description is multi-line, start the description on the next line and indent it consistently. lgtm. pgpMNovZHNU66.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/3] show: Introduce mime_node formatter callback
On Wed, 18 Jan 2012 15:28:27 -0500, Austin Clements amdra...@mit.edu wrote:
This callback is the gateway to the new mime_node_t-based formatters.
This maintains backwards compatibility so the formatters can be
transitioned one at a time. Once all formatters are converted, the
formatter structure can be reduced to only message_set_{start,sep,end}
and part, most of show_message can be deleted, and all of
show-message.c can be deleted.
---
notmuch-client.h |6 ++
notmuch-reply.c |2 +-
notmuch-show.c | 22 ++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index b3dcb6b..3ccdfad 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -54,8 +54,14 @@
#define STRINGIFY(s) STRINGIFY_(s)
#define STRINGIFY_(s) #s
+struct mime_node;
+struct notmuch_show_params;
+
typedef struct notmuch_show_format {
const char *message_set_start;
+void (*part) (const void *ctx,
+ struct mime_node *node, int indent,
+ struct notmuch_show_params *params);
const char *message_start;
void (*message) (const void *ctx,
notmuch_message_t *message,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 0f682db..9a224e2 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -31,7 +31,7 @@ static void
reply_part_content (GMimeObject *part);
static const notmuch_show_format_t format_reply = {
-,
+, NULL,
, NULL,
, NULL, reply_headers_message_part, \n,
,
diff --git a/notmuch-show.c b/notmuch-show.c
index ecadfa8..46eef44 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -42,7 +42,7 @@ static void
format_part_end_text (GMimeObject *part);
static const notmuch_show_format_t format_text = {
-,
+, NULL,
\fmessage{ , format_message_text,
\fheader{\n, format_headers_text,
format_headers_message_part_text, \fheader}\n,
\fbody{\n,
@@ -85,7 +85,7 @@ static void
format_part_end_json (GMimeObject *part);
static const notmuch_show_format_t format_json = {
-[,
+[, NULL,
{, format_message_json,
\headers\: {, format_headers_json,
format_headers_message_part_json, },
, \body\: [,
@@ -106,7 +106,7 @@ format_message_mbox (const void *ctx,
unused (int indent));
static const notmuch_show_format_t format_mbox = {
-,
+, NULL,
, format_message_mbox,
, NULL, NULL, ,
,
@@ -125,7 +125,7 @@ static void
format_part_content_raw (GMimeObject *part);
static const notmuch_show_format_t format_raw = {
-,
+, NULL,
, NULL,
, NULL, format_headers_message_part_text, \n,
,
@@ -762,6 +762,20 @@ show_message (void *ctx,
int indent,
notmuch_show_params_t *params)
{
+if (format-part) {
+ void *local = talloc_new (ctx);
+ mime_node_t *root, *part;
+
+ if (mime_node_open (local, message, params-cryptoctx, params-decrypt,
+ root) != NOTMUCH_STATUS_SUCCESS)
I'm new to talloc, I think I like it, but I always find it confusing
when some code paths free the contexts, and some don't. Like here.
Are you not freeing the local context here because it's just an empty
context, and freeing below because it's no longer empty?
No need to change anything, I guess, just asking...
BR,
Jani.
+ return;
+ part = mime_node_seek_dfs (root, params-part 0 ? 0 : params-part);
+ if (part)
+ format-part (local, part, indent, params);
+ talloc_free (local);
+ return;
+}
+
if (params-part = 0) {
fputs (format-message_start, stdout);
if (format-message)
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Sort by newest first from notmuch-hello ?
Hi, I am running latest release (0.11). I have set notmuch-search-oldest-first to t. When doing M-x notmuch-search, messages order does not respect this setting -i.e newest com firts -. On the other hand, from notmuch-hello I get expected behaviour. How can this be more consistent ? By the way, am I alone having hundreds thousand messages ? If not, what would you thing setting this variable to `nil' by default ? Having first messages at the top would be more usefull that scrolling down really far ;-) Regards /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 2/4] reply: Add a JSON reply format.
On Mon, 16 Jan 2012 11:13:21 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca
wrote:
This new JSON format for replies includes headers generated for a reply
message as well as the headers and all text parts of the original message.
Using this data, a client can intelligently create a reply. For example,
the emacs client will be able to create replies with quoted HTML parts by
parsing the HTML parts using w3m.
Hi, admittedly not a very thorough review, but please find a couple of
comments below.
BR,
Jani.
---
notmuch-reply.c | 313
---
1 files changed, 253 insertions(+), 60 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index da3acce..f5a5dcf 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -30,6 +30,15 @@ reply_headers_message_part (GMimeMessage *message);
static void
reply_part_content (GMimeObject *part);
+static void
+reply_part_start_json (GMimeObject *part, int *part_count);
+
+static void
+reply_part_content_json (GMimeObject *part);
+
+static void
+reply_part_end_json (GMimeObject *part);
+
static const notmuch_show_format_t format_reply = {
,
, NULL,
@@ -46,6 +55,22 @@ static const notmuch_show_format_t format_reply = {
};
+static const notmuch_show_format_t format_json = {
+,
+ , NULL,
+ , NULL, NULL, ,
+ ,
+ reply_part_start_json,
+ NULL,
+ NULL,
+ reply_part_content_json,
+ reply_part_end_json,
+ ,
+ ,
+ , ,
+
+};
+
static void
show_reply_headers (GMimeMessage *message)
{
@@ -54,14 +79,14 @@ show_reply_headers (GMimeMessage *message)
stream_stdout = g_mime_stream_file_new (stdout);
if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
- stream_filter = g_mime_stream_filter_new(stream_stdout);
+ stream_filter = g_mime_stream_filter_new (stream_stdout);
if (stream_filter) {
- g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
- g_mime_filter_headers_new());
- g_mime_object_write_to_stream(GMIME_OBJECT(message),
stream_filter);
- g_object_unref(stream_filter);
+ g_mime_stream_filter_add (GMIME_STREAM_FILTER(stream_filter),
+ g_mime_filter_headers_new());
+ g_mime_object_write_to_stream (GMIME_OBJECT(message),
stream_filter);
+ g_object_unref (stream_filter);
}
- g_object_unref(stream_stdout);
+ g_object_unref (stream_stdout);
I know I asked you to adhere to notmuch coding style like above, but I
meant in the context of your patch, not elsewhere. Cleanups like this
should really be separate patches. Sorry if I was ambiguous.
}
}
@@ -86,6 +111,17 @@ reply_headers_message_part (GMimeMessage *message)
printf ( Date: %s\n, g_mime_message_get_date_as_string (message));
}
+static notmuch_bool_t
+reply_check_part_type (GMimeObject *part, const char *type, const char
*subtype,
+const char *disposition)
+{
+GMimeContentType *content_type = g_mime_object_get_content_type
(GMIME_OBJECT (part));
+GMimeContentDisposition *part_disposition =
g_mime_object_get_content_disposition (part);
+
+return (g_mime_content_type_is_type (content_type, type, subtype)
+ (!part_disposition ||
+ strcmp (part_disposition-disposition, disposition) == 0));
+}
static void
reply_part_content (GMimeObject *part)
@@ -108,32 +144,29 @@ reply_part_content (GMimeObject *part)
{
GMimeStream *stream_stdout = NULL, *stream_filter = NULL;
GMimeDataWrapper *wrapper;
- const char *charset;
-
- charset = g_mime_object_get_content_type_parameter (part, charset);
stream_stdout = g_mime_stream_file_new (stdout);
if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout),
FALSE);
- stream_filter = g_mime_stream_filter_new(stream_stdout);
- if (charset) {
- g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
- g_mime_filter_charset_new(charset,
UTF-8));
- }
+ stream_filter = g_mime_stream_filter_new (stream_stdout);
+
+ const char *charset = g_mime_object_get_content_type_parameter
(part, charset);
+ if (charset)
+ g_mime_stream_filter_add(GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_charset_new (charset,
UTF-8));
}
- g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
- g_mime_filter_reply_new(TRUE));
+ g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+
Re: [PATCH v2 2/4] reply: Add a JSON reply format.
On Wed, Jan 18, 2012 at 16:07, Jani Nikula j...@nikula.org wrote: I know I asked you to adhere to notmuch coding style like above, but I meant in the context of your patch, not elsewhere. Cleanups like this should really be separate patches. Sorry if I was ambiguous. Oops - my bad. I assumed I had introduced all the spacing problems in the file and blindly fixed them. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 10:50:50 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: I've been wanting to put together a wiki page that lists all the useful functions and has examples of how to put them together into useful functions. If we're going to go the way of providing a toolkit/api for uses to make their own bindings, then I think that we should make the effort to provide a proper info document with the distribution, rather than relying on the wiki. Of course, that means more work, and yet another markup language, I guess. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/2] Fix or silence unused result warnings
I'm afraid I bikeshedded dme's original patch for this into oblivion (id:1324503532-5799-1-git-send-email-...@dme.org) and we still have these warnings on the buildbot. Tomi convinced me that dme was right and I was wrong, so I'm bringing dme's patch back. The first patch actually fixes the warning, since the code in show was wantonly ignoring errors that could have correctness implications. This write didn't get much attention in the original thread. The second is a rework of dme's patch to silence the warning for the remaining writes. I cleaned up the formatting, simplified the macro magic a little, and added a comment justifying its use. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] Silence buildbot warnings about unused results
This ignores the results of the two writes in sigint handlers even
harder than before.
While my libc lacks the declarations that trigger these warnings, this
can be tested by adding the following to notmuch.h:
__attribute__((warn_unused_result))
ssize_t write(int fd, const void *buf, size_t count);
---
compat/compat.h |8
notmuch-new.c |6 +-
notmuch-tag.c |5 -
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/compat/compat.h b/compat/compat.h
index 7767fe8..b2e2736 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -46,6 +46,14 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE
*fp);
char* strcasestr(const char *haystack, const char *needle);
#endif /* !HAVE_STRCASESTR */
+/* Silence gcc warnings about unused results. These warnings exist
+ * for a reason; any use of this needs to be justified. */
+#ifdef __GNUC__
+#define IGNORE_RESULT(x) ({ __typeof__(x) __z = (x); (void)(__z = __z); })
+#else /* !__GNUC__ */
+#define IGNORE_RESULT(x) x
+#endif /* __GNUC__ */
+
#ifdef __cplusplus
}
#endif
diff --git a/notmuch-new.c b/notmuch-new.c
index 3512de7..a569a54 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -67,7 +67,11 @@ handle_sigint (unused (int sig))
{
static char msg[] = Stopping... \n;
-(void) write(2, msg, sizeof(msg)-1);
+/* This write is opportunistic, so it's okay to ignore the
+ * result. It is not required for correctness, and if it does
+ * fail or produce a short write, we want to get out of the signal
+ * handler as quickly as possible, not retry it. */
+IGNORE_RESULT (write (2, msg, sizeof(msg)-1));
interrupted = 1;
}
diff --git a/notmuch-tag.c b/notmuch-tag.c
index 292c5da..1564182 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,10 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = Stopping... \n;
-(void) write(2, msg, sizeof(msg)-1);
+
+/* See handle_sigint in notmuch-new.c for the justification for
+ * ignoring write's result. */
+IGNORE_RESULT (write (2, msg, sizeof(msg)-1));
interrupted = 1;
}
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] show: Handle read and write errors
For showing a message in raw format, rather than silently succeeding
when a read or a write fails (or, probably, looping if a read fails),
try to print an error message and exit with a non-zero status.
This silences one of the buildbot warnings about unused resuls. While
my libc lacks the declarations that trigger these warnings, this can
be tested by adding the following to notmuch.h:
__attribute__((warn_unused_result))
size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
---
notmuch-show.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..c674e25 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -883,7 +883,17 @@ do_show_single (void *ctx,
while (!feof (file)) {
size = fread (buf, 1, sizeof (buf), file);
- (void) fwrite (buf, size, 1, stdout);
+ if (ferror (file)) {
+ fprintf (stderr, Error: Read failed from %s\n, filename);
+ fclose (file);
+ return 1;
+ }
+
+ if (fwrite (buf, size, 1, stdout) != 1) {
+ fprintf (stderr, Error: Write failed\n);
+ fclose (file);
+ return 1;
+ }
}
fclose (file);
--
1.7.7.3
___
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'
Quoth Aaron Ecay on Jan 18 at 5:18 pm: 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.) I agree with Aaron. There's no excuse for some of the functionality that can only be found in cl to be missing from core Emacs and it's ridiculous to re-implement it time and again (I count at least five obvious reimplementations of remove-if in code shipped with Emacs). There are a lot of compelling reasons to use cl and I'm not aware of any good technical reasons why notmuch shouldn't. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] mime node: Record depth-first part numbers
Quoth Jani Nikula on Jan 19 at 12:25 am:
On Wed, 18 Jan 2012 15:28:25 -0500, Austin Clements amdra...@mit.edu wrote:
This makes the part numbers readily accessible to formatters.
Hierarchical part numbering would be a more natural and efficient fit
for MIME and may be the way to go in the future, but depth-first
numbering maintains compatibility with what we currently do.
Hi, please find a few things to consider below. If you disagree after
considering, it's quite all right, as they're largely style matters. :)
BR,
Jani.
---
mime-node.c | 33 -
notmuch-client.h | 11 +++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index d26bb44..30b542f 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t
*message,
root-nchildren = 1;
root-ctx = mctx;
+root-part_num = 0;
+root-next_child = 0;
+root-next_part_num = 1;
+
*root_out = root;
return NOTMUCH_STATUS_SUCCESS;
@@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent,
GMimeObject *part)
talloc_free (node);
return NULL;
}
+node-parent = parent;
+node-part_num = node-next_part_num = -1;
/* Deal with the different types of parts */
if (GMIME_IS_PART (part)) {
@@ -217,6 +223,7 @@ mime_node_t *
mime_node_child (const mime_node_t *parent, int child)
{
GMimeObject *sub;
+mime_node_t *node;
if (!parent || child 0 || child = parent-nchildren)
return NULL;
@@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)
INTERNAL_ERROR (Unexpected GMimeObject type: %s,
g_type_name (G_OBJECT_TYPE (parent-part)));
}
-return _mime_node_create (parent, sub);
+node = _mime_node_create (parent, sub);
+
+if (child == parent-next_child parent-next_part_num != -1) {
+ /* We're traversing in depth-first order. Record the child's
+* depth-first numbering. */
+ node-part_num = parent-next_part_num;
+ node-next_part_num = node-part_num + 1;
+
+ /* Drop the const qualifier because these are internal fields
+* whose mutability doesn't affect the interface. */
FWIW, I'm not a big fan of casting away const. Either it is const, or it
isn't. Not very many places would be affected if you dropped the const
qualifier from the related interface(s) altogether, and things would
look cleaner here. But I suppose this is a matter of taste.
I'm not particularly happy with this either. Unfortunately, dropping
the const here affects a surprising number of places, including the
entire MIME node API.
I think that, at a deep level, depth-first numbering simply doesn't
resonate with an extremely hierarchical API like this and that
dissonance is going to have to focus somewhere. There have been
discussions of switching to hierarchical part numbering before (in
particular, because depth-first numbering is unstable with encrypted
parts) and I'll probably restart those after all of this is done.
+ ((mime_node_t*)parent)-next_child++;
+ ((mime_node_t*)parent)-next_part_num = -1;
+
+ if (node-nchildren == 0) {
+ /* We've reached a leaf, so find the parent that has more
+* children and set it up to number its next child. */
+ const mime_node_t *it = node;
+ while (it it-next_child == it-nchildren)
+ it = it-parent;
+ if (it)
+ ((mime_node_t*)it)-next_part_num = node-part_num + 1;
+ }
+}
Following the constness around made me wonder why the above if block
isn't within _mime_node_create(). It does have a feel of initialization
related to creation in it. (You'd have to pass more info to it though.)
I considered this, but was dissuaded by having to pass redundant
information to _mime_node_create. I think it's okay here because it
has as much to do with child fetching as with initialization, but I
could easily be swayed.
+
+return node;
}
static mime_node_t *
diff --git a/notmuch-client.h b/notmuch-client.h
index 62ede28..b3dcb6b 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -281,6 +281,13 @@ typedef struct mime_node {
/* The number of children of this part. */
int nchildren;
+/* The parent of this node or NULL if this is the root node. */
+const struct mime_node *parent;
+
+/* The depth-first part number of this child if the MIME tree is
+ * being traversed in depth-first order, or -1 otherwise. */
+int part_num;
+
/* True if decryption of this part was attempted. */
notmuch_bool_t decrypt_attempted;
/* True if decryption of this part's child succeeded. In this
@@ -302,6 +309,10 @@ typedef struct mime_node {
/* Internal: For successfully
Re: RFC: tag macros
On Wed, 18 Jan 2012 20:04:44 -0400, David Bremner da...@tethera.net wrote: If we're going to go the way of providing a toolkit/api for uses to make their own bindings, then I think that we should make the effort to provide a proper info document with the distribution, rather than relying on the wiki. Of course, that means more work, and yet another markup language, I guess. Can't we just use the emacs build-in documentation? My idea of documenting on the wiki was just as a starting point. It could list some of the available functions, and how to use them, and then have good references to emacs documentation and how to find it. I'm guessing we also have a lot of functions that are marked interactive that don't necessarily need to be. Weeding those out might make documentation easier. jamie. pgpHgmjGJsqHB.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/3] show: Introduce mime_node formatter callback
Quoth Jani Nikula on Jan 19 at 12:33 am:
On Wed, 18 Jan 2012 15:28:27 -0500, Austin Clements amdra...@mit.edu wrote:
This callback is the gateway to the new mime_node_t-based formatters.
This maintains backwards compatibility so the formatters can be
transitioned one at a time. Once all formatters are converted, the
formatter structure can be reduced to only message_set_{start,sep,end}
and part, most of show_message can be deleted, and all of
show-message.c can be deleted.
---
notmuch-client.h |6 ++
notmuch-reply.c |2 +-
notmuch-show.c | 22 ++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index b3dcb6b..3ccdfad 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -54,8 +54,14 @@
#define STRINGIFY(s) STRINGIFY_(s)
#define STRINGIFY_(s) #s
+struct mime_node;
+struct notmuch_show_params;
+
typedef struct notmuch_show_format {
const char *message_set_start;
+void (*part) (const void *ctx,
+ struct mime_node *node, int indent,
+ struct notmuch_show_params *params);
const char *message_start;
void (*message) (const void *ctx,
notmuch_message_t *message,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 0f682db..9a224e2 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -31,7 +31,7 @@ static void
reply_part_content (GMimeObject *part);
static const notmuch_show_format_t format_reply = {
-,
+, NULL,
, NULL,
, NULL, reply_headers_message_part, \n,
,
diff --git a/notmuch-show.c b/notmuch-show.c
index ecadfa8..46eef44 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -42,7 +42,7 @@ static void
format_part_end_text (GMimeObject *part);
static const notmuch_show_format_t format_text = {
-,
+, NULL,
\fmessage{ , format_message_text,
\fheader{\n, format_headers_text,
format_headers_message_part_text, \fheader}\n,
\fbody{\n,
@@ -85,7 +85,7 @@ static void
format_part_end_json (GMimeObject *part);
static const notmuch_show_format_t format_json = {
-[,
+[, NULL,
{, format_message_json,
\headers\: {, format_headers_json,
format_headers_message_part_json, },
, \body\: [,
@@ -106,7 +106,7 @@ format_message_mbox (const void *ctx,
unused (int indent));
static const notmuch_show_format_t format_mbox = {
-,
+, NULL,
, format_message_mbox,
, NULL, NULL, ,
,
@@ -125,7 +125,7 @@ static void
format_part_content_raw (GMimeObject *part);
static const notmuch_show_format_t format_raw = {
-,
+, NULL,
, NULL,
, NULL, format_headers_message_part_text, \n,
,
@@ -762,6 +762,20 @@ show_message (void *ctx,
int indent,
notmuch_show_params_t *params)
{
+if (format-part) {
+ void *local = talloc_new (ctx);
+ mime_node_t *root, *part;
+
+ if (mime_node_open (local, message, params-cryptoctx, params-decrypt,
+ root) != NOTMUCH_STATUS_SUCCESS)
I'm new to talloc, I think I like it, but I always find it confusing
when some code paths free the contexts, and some don't. Like here.
Are you not freeing the local context here because it's just an empty
context, and freeing below because it's no longer empty?
No, that's just a bug. In practice it probably doesn't matter much
because, as you pointed out, the local context consumes very little
memory and since the caller will eventually free ctx, local will get
cleaned up, too. So, while this isn't strictly a memory leak, in
principle this could add up before ctx gets freed. Fixed.
No need to change anything, I guess, just asking...
I wait a little for other comments and then send a new version.
Thanks for the review!
BR,
Jani.
+ return;
+ part = mime_node_seek_dfs (root, params-part 0 ? 0 : params-part);
+ if (part)
+ format-part (local, part, indent, params);
+ talloc_free (local);
+ return;
+}
+
if (params-part = 0) {
fputs (format-message_start, stdout);
if (format-message)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: tag macros
On Wed, 18 Jan 2012 18:15:37 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Can't we just use the emacs build-in documentation? If you mean docstrings, that is only per function/variable. Which is better than nothing, but not very good for getting an overview of what is going on. Otherwise, info _is_ emacs' built-in documentation. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] Silence buildbot warnings about unused results
On Wed, 18 Jan 2012 19:40:11 -0500, Austin Clements amdra...@mit.edu wrote: +/* See handle_sigint in notmuch-new.c for the justification for + * ignoring write's result. */ +IGNORE_RESULT (write (2, msg, sizeof(msg)-1)); Just include the comment in both places. Someone will work over the code in notmuch-new.c and we'll lose it. Then, +1. pgpWXU9Y5mX3J.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] emacs: bind "s" to `notmuch-search' in notmuch-hello buffer
[of course I sent this email privately, sorry for duplicates] On Tue, 17 Jan 2012 23:22:30 +0200, Jani Nikula wrote: > On Tue, 17 Jan 2012 23:34:08 +0400, Dmitry Kurochkin gmail.com> wrote: > > Before the change, "s" in notmuch-hello buffer would jump to the > > search box. The patch changes the binding to `notmuch-search' which > > is consistent with all other notmuch buffers. > > --- > > emacs/notmuch-hello.el | 19 ++- > > 1 files changed, 6 insertions(+), 13 deletions(-) > > > > diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el > > index 02017ce..08fcd22 100644 > > --- a/emacs/notmuch-hello.el > > +++ b/emacs/notmuch-hello.el > > @@ -29,9 +29,6 @@ > > (declare-function notmuch-search "notmuch" (query oldest-first > > target-thread target-line continuation)) > > (declare-function notmuch-poll "notmuch" ()) > > > > -(defvar notmuch-hello-search-bar-marker nil > > - "The position of the search bar within the notmuch-hello buffer.") > > - > > (defcustom notmuch-recent-searches-max 10 > >"The number of recent searches to store and display." > >:type 'integer > > @@ -321,11 +318,6 @@ should be. Returns a cons cell `(tags-per-line > > width)'." > > (widget-insert "\n")) > > found-target-pos)) > > > > -(defun notmuch-hello-goto-search () > > - "Put point inside the `search' widget." > > - (interactive) > > - (goto-char notmuch-hello-search-bar-marker)) > > After this, what would the user have to do to bind some key to put the > point in the search box? If someone wants to restore old behaviour for > themselves. > There is no way to do that. From the previous discussions, I do not remember anyone wanted the current "s" jumping behavior. Let's wait for some feedback and see if anyone wants that. I would prefer to remove this function and the global variable it uses. > Also, it's perhaps out of scope for this patch, but it will become more > evident now that notmuch-search does not respect > notmuch-search-oldest-first when called without parameters like the new > 's' keybinding does. This is the same in search view. > I agree that this is an issue. But it is outisde of the scope of this patch series. Regards, Dmitry > > BR, > Jani. > > > > - > > (defimage notmuch-hello-logo ((:type png :file "notmuch-logo.png"))) > > > > (defun notmuch-hello-search-continuation() > > @@ -355,7 +347,7 @@ should be. Returns a cons cell `(tags-per-line width)'." > > (define-key map "G" 'notmuch-hello-poll-and-update) > > (define-key map (kbd "") 'widget-backward) > > (define-key map "m" 'notmuch-mua-new-mail) > > -(define-key map "s" 'notmuch-hello-goto-search) > > +(define-key map "s" 'notmuch-search) > > map) > >"Keymap for \"notmuch hello\" buffers.") > > (fset 'notmuch-hello-mode-map notmuch-hello-mode-map) > > @@ -468,7 +460,8 @@ Complete list of currently available key bindings: > >(widget-insert " messages.\n")) > > > > (let ((found-target-pos nil) > > - (final-target-pos nil)) > > + (final-target-pos nil) > > + (search-bar-pos)) > >(let* ((saved-alist > > ;; Filter out empty saved searches if required. > > (if notmuch-show-empty-saved-searches > > @@ -500,7 +493,7 @@ Complete list of currently available key bindings: > > (indent-rigidly start (point) notmuch-hello-indent))) > > > > (widget-insert "\nSearch: ") > > - (setq notmuch-hello-search-bar-marker (point-marker)) > > + (setq search-bar-pos (point-marker)) > > (widget-create 'editable-field > >;; Leave some space at the start and end of the > >;; search boxes. > > @@ -589,7 +582,7 @@ Complete list of currently available key bindings: > > (when notmuch-saved-searches > > (widget-insert "Edit saved searches with the `edit' button.\n")) > > (widget-insert "Hit RET or click on a saved search or tag name to view > > matching threads.\n") > > - (widget-insert "`=' refreshes this screen. `s' jumps to the search box. > > `q' to quit.\n") > > + (widget-insert "`=' refreshes this screen. `s' to search messages. `q' > > to quit.\n") > > (let ((fill-column (- (window-width) notmuch-hello-indent))) > > (center-region start (point > > > > @@ -601,7 +594,7 @@ Complete list of currently available key bindings: > > (widget-forward 1))) > > > >(unless (widget-at) > > - (notmuch-hello-goto-search > > + (goto-char search-bar-pos > > > >(run-hooks 'notmuch-hello-refresh-hook)) > > > > -- > > 1.7.8.3 > > > > ___ > > notmuch mailing list > > notmuch at notmuchmail.org > > http://notmuchmail.org/mailman/listinfo/notmuch
Improving notmuch query documentation [was: Re: Partial words on notmuch search?]
On Lu, 16 ian 12, 21:34:31, Austin Clements wrote: > Quoth Andrei Popescu on Jan 16 at 10:21 pm: > > This is also interesting: > > $ notmuch count 'debian' > > 65888 > > $ notmuch count 'dEbian' > > 65888 > > $ notmuch count 'Debian' > > 65887 > > The first two will match stemmed versions of "debian" such as > "debian's" and "debianed". However, starting a term with a capital > letter suppresses stemming (because it suggests that it's a name, > which you wouldn't want to modify), so your last query matches only > the term "debian". This is probably documented somewhere, though I > don't know where. Stemming is mentioned in the Xapian docs, but I didn't understand the meaning until I read your explanation, thanks :) > > Where can I read more about this? (except the source :) > > Most of this is in the Xapian query syntax document you found. Really > we ought to beef-up Notmuch's query syntax documentation. If I get around to write something myself where do you suggest I should start, the wiki or the manpage? Thanks, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120118/d4b267ff/attachment.pgp>
[PATCH v3] Make buttons for attachments allow viewing as well as saving
> Oof, sorry. Two more tweaks that I really should have caught in the > previous version. After that this gets my automatic +1. Both fixed. I have also fixed the bug I mentioned (missing filename when "view" falls back on save); I couldn't make it work with the "no-default" option. However overriding mm-save-part with flet seems to do the trick. +(defun notmuch-show-view-part (message-id nth filename content-type ) + (notmuch-with-temp-part-buffer message-id nth +;; set mm-inlined-types to nil to force an external viewer +(let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + ;; We override mm-save-part as notmuch-show-save-part is better + ;; since it offers the filename + (flet ((mm-save-part ( args) (ignore))) + (or (mm-display-part handle) + (notmuch-show-save-part message-id nth filename content-type)) Is that a reasonable solution? Best wishes Mark
[PATCH v2 4/5] emacs: Use the new JSON reply format.
On Tue, 17 Jan 2012 15:53:37 -0700, Adam Wolfe Gordon <awg+notmuch at xvx.ca> wrote: > +(defun notmuch-parts-filter-by-type (parts type) > + "Return a list of message parts with the given type" > + (let (result) > +(dolist (part (append parts nil) result) > + (if (string= (cdr (assq 'content-type part)) type) > + (setq result (append result (list (cdr (assq 'content part))) > +result)) I still think that `loop' is easier to read :-) But no objection to this code. > +(defun notmuch-mua-insert-part-quoted (part) > + (let ((start (point)) > + limit) > +(insert part) > +(setq limit (point)) > +(goto-char start) > +(while (re-search-forward "\\(^\\)[^$]" limit 0) > + (replace-match "> " nil nil nil 1) > + ;; We have added two characters to the quotable region > + (setq limit (+ limit 2))) > +(set-buffer-modified-p nil))) You could use a marker for the limit, as it would then move along automagically (sorry for not noticing this last time). -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120118/261935f8/attachment.pgp>
ANNOUNCE: nottoomuch-addresses.sh 2.0
nottoomuch-addresses.sh -- email address substring matcher -- completion helper version 2.0 is available. Note to 1.92 prerelease tester(s): ignore regexp "indicator" has changed from ^re:... to ^/.../[i]. This allows this 'i' flag and trailing whitespace in re. Changes: * Added regexp-based ignores using /regexp/[i] syntax in ignore file. * Addresses 'cache' now contains all addresses and filreted (by ignore) are now in separate file. This way changes in ignore filters can be propagated to active address list. * Encoded address content is now recursively decoded. Header version was changed but this version supports "importing" data from older versions. In case you had ignore filters defined (or recursively encoded mailbox/comment names) it is recommended to rebuils address cache with /path/to/nottoomuch-addresses.sh --update --rebuild Location: http://www.iki.fi/too/nottoomuch/nottoomuch-addresses.sh Sha1sum (not md5sum): 343833fce0a30ddae859eff4a31d6153fa9c81f9 Web page: http://www.iki.fi/too/nottoomuch/nottoomuch-addresses/ Enjoy! Tomi
[PATCH] emacs: Improved printing support.
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!
Add a keybinding to `notmuch-show-mode'.
emacs/Makefile.local |3 +-
emacs/notmuch-print.el | 85
emacs/notmuch-show.el | 53 ++
3 files changed, 140 insertions(+), 1 deletions(-)
create mode 100644 emacs/notmuch-print.el
diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 0c58b82..4fee0e8 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -13,7 +13,8 @@ emacs_sources := \
$(dir)/notmuch-maildir-fcc.el \
$(dir)/notmuch-message.el \
$(dir)/notmuch-crypto.el \
- $(dir)/coolj.el
+ $(dir)/coolj.el \
+ $(dir)/notmuch-print.el
emacs_images := \
$(srcdir)/$(dir)/notmuch-logo.png
diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
new file mode 100644
index 000..77f10bb
--- /dev/null
+++ b/emacs/notmuch-print.el
@@ -0,0 +1,85 @@
+;; notmuch-print.el --- printing messages from notmuch.
+;;
+;; Copyright ? David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch. If not, see
[PATCH 1/6] emacs: break up notmuch-show-archive-thread-internal into two generally useful functions
Very happy with the overall ideas. On Tue, 17 Jan 2012 10:05:26 -0800, Jameson Graef Rollins wrote: > -(defun notmuch-show-archive-thread-internal (show-next) > - ;; Remove the tag from the current set of messages. > +(defun notmuch-show-tag-thread-internal (tag remove) > + ;; Add tag to the current set of messages. If the remove switch is > + ;; given, tags will be removed instead of added. >(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 ((tag-function 'notmuch-show-add-tag)) > +(if remove > + (setq tag-function 'notmuch-show-remove-tag)) This seems odd. How about: (let ((tag-function (if remove 'notmuch-show-remove-tag 'notmuch-show-add-tag))) ... > +(loop do (funcall tag-function tag) > + until (not (notmuch-show-goto-message-next) Otherwise good. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120118/3b9a1657/attachment.pgp>
