From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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