From edd6e0aefa18108a40adeeaee22df244aa423219 Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Mon, 31 Aug 2015 22:01:22 +0300 Subject: [PATCH] Re: [PATCH 2/2] emacs: add function to resend message to new recipients --- 08/37cd7827989743f3ca841c3b7938d71bbc570e | 107 ++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 08/37cd7827989743f3ca841c3b7938d71bbc570e diff --git a/08/37cd7827989743f3ca841c3b7938d71bbc570e b/08/37cd7827989743f3ca841c3b7938d71bbc570e new file mode 100644 index 000000000..b18ec40cb --- /dev/null +++ b/08/37cd7827989743f3ca841c3b7938d71bbc570e @@ -0,0 +1,107 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id A90FD6DE0B2F + for ; Mon, 31 Aug 2015 12:02:53 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: 1.202 +X-Spam-Level: * +X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=-0.194, + SPF_NEUTRAL=0.652, URIBL_SBL=0.644, URIBL_SBL_A=0.1] autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id AuKECO7ZtDM7 for ; + Mon, 31 Aug 2015 12:02:51 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by arlo.cworth.org (Postfix) with ESMTP id 3274B6DE00CB + for ; Mon, 31 Aug 2015 12:02:50 -0700 (PDT) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id BA3D510005A; + Mon, 31 Aug 2015 22:01:22 +0300 (EEST) +From: Tomi Ollila +To: David Bremner , notmuch@notmuchmail.org +Subject: Re: [PATCH 2/2] emacs: add function to resend message to new + recipients +In-Reply-To: <87lhcss06e.fsf@maritornes.cs.unb.ca> +References: <1440619626-18768-1-git-send-email-tomi.ollila@iki.fi> + <1440619626-18768-2-git-send-email-tomi.ollila@iki.fi> + <87vbbxrl3g.fsf@maritornes.cs.unb.ca> + <87lhcss06e.fsf@maritornes.cs.unb.ca> +User-Agent: Notmuch/0.20.2+68~g0c35549 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.18 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 31 Aug 2015 19:02:53 -0000 + +On Mon, Aug 31 2015, David Bremner wrote: + +> Tomi Ollila writes: +> +>> +>> emacs -q -L $PWD/emacs -l emacs/notmuch.el -f notmuch --eval '(progn (setq notmuch-address-command "nottoomuch-addresses.sh") (notmuch-address-message-insinuate))' +>> + +> Ah, I missed notmuch-address-message-insinuate; it does work if I run +> that. I wonder if this can be simplified at all now that +> notmuch-message-mode exists. In general I'm leery of running code when we +> load notmuch*.el, as this has a history of causing problems for people +> using notmuch e.g. as a search tool for gnus. + +Currently as both setting notmuch-address-command and +notmuch-address-message-insinunate us required I would not attempt to do any +"magic" there. Whenever we get built-in address completion (i.e built-in +is used when notmuch-address-command is kept nil we could consider to add +some defcustom which can be used to activate address completion -- but +as there are these *-insinunate -commands in many elisp packages it is +probably best to investigate whether this really can be "automated". +Perhaps some lazy initialization could be in place, then. + +> The completion interface takes a little getting used to, but it's +> definitely usable. And of course much better than what we have now ;). +> +> One thing I noticed which I _think_ is a bug, is that after calling +> notmuch-show-resend-message, notmuch-view-raw-message doesn't work +> anymore, complaining about a read-only buffer. + +That is interesting in a sense that I could not reproduce. I think I know +exactly why this happens: notmuch-view-raw-message creates read-only buffer +which is not removed after message is resent: re-running +notmuch-view-raw-message on same message will `get-buffer-create' with +same name and pick the old read-only buffer; inserting data to that buffer +fails -- just that in my tests (V C-x b RET V) I could not get the same +outcome. + +The simplest change is to change (bury-buffer) with (kill-buffer). The raw +message buffer that was used to send should not be interesting; more +interesting is the current (same) message in notmuch-show buffer -- and 'V' +can be used to re-view the raw message. +What could be added is printing the message id of the message resent to +*Messages* buffer. This way re-sender can verify what was resent if being +unsure. Just that in the case I've used this I have not looked back... + +So, probably I make applicable RFC patch of this feature... + + +> +> d + +Tomi -- 2.26.2