08/37cd7827989743f3ca841c3b7938d71bbc570e

   1 Return-Path: <tomi.ollila@iki.fi>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id A90FD6DE0B2F\r
   6  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 12:02:53 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 1.202\r
  10 X-Spam-Level: *\r
  11 X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=-0.194,\r
  12   SPF_NEUTRAL=0.652, URIBL_SBL=0.644, URIBL_SBL_A=0.1] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id AuKECO7ZtDM7 for <notmuch@notmuchmail.org>;\r
  16  Mon, 31 Aug 2015 12:02:51 -0700 (PDT)\r
  17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 3274B6DE00CB\r
  19  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 12:02:50 -0700 (PDT)\r
  20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
  21  by guru.guru-group.fi (Postfix) with ESMTP id BA3D510005A;\r
  22  Mon, 31 Aug 2015 22:01:22 +0300 (EEST)\r
  23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  24 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
  25 Subject: Re: [PATCH 2/2] emacs: add function to resend message to new\r
  26  recipients\r
  27 In-Reply-To: <87lhcss06e.fsf@maritornes.cs.unb.ca>\r
  28 References: <1440619626-18768-1-git-send-email-tomi.ollila@iki.fi>\r
  29  <1440619626-18768-2-git-send-email-tomi.ollila@iki.fi>\r
  30  <87vbbxrl3g.fsf@maritornes.cs.unb.ca> <m2a8t8257b.fsf@guru.guru-group.fi>\r
  31  <87lhcss06e.fsf@maritornes.cs.unb.ca>\r
  32 User-Agent: Notmuch/0.20.2+68~g0c35549 (http://notmuchmail.org) Emacs/24.3.1\r
  33  (x86_64-unknown-linux-gnu)\r
  34 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  35  $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  36  !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  37 Date: Mon, 31 Aug 2015 22:01:22 +0300\r
  38 Message-ID: <m2si6zffjx.fsf@guru.guru-group.fi>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: text/plain\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.18\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45  <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Mon, 31 Aug 2015 19:02:53 -0000\r
  54 \r
  55 On Mon, Aug 31 2015, David Bremner <david@tethera.net> wrote:\r
  56 \r
  57 > Tomi Ollila <tomi.ollila@iki.fi> writes:\r
  58 >\r
  59 >>\r
  60 >>   emacs -q -L $PWD/emacs -l emacs/notmuch.el -f notmuch --eval '(progn (setq notmuch-address-command "nottoomuch-addresses.sh") (notmuch-address-message-insinuate))'\r
  61 >>\r
  62 \r
  63 > Ah, I missed notmuch-address-message-insinuate; it does work if I run\r
  64 > that. I wonder if this can be simplified at all now that\r
  65 > notmuch-message-mode exists. In general I'm leery of running code when we\r
  66 > load notmuch*.el, as this has a history of causing problems for people\r
  67 > using notmuch e.g. as a search tool for gnus.\r
  68 \r
  69 Currently as both setting notmuch-address-command and\r
  70 notmuch-address-message-insinunate us required I would not attempt to do any\r
  71 "magic" there. Whenever we get built-in address completion (i.e built-in\r
  72 is used when notmuch-address-command is kept nil we could consider to add\r
  73 some defcustom which can be used to activate address completion -- but \r
  74 as there are these *-insinunate -commands in many elisp packages it is\r
  75 probably best to investigate whether this really can be "automated".\r
  76 Perhaps some lazy initialization could be in place, then.\r
  77 \r
  78 > The completion interface takes a little getting used to, but it's\r
  79 > definitely usable. And of course much better than what we have now ;).\r
  80 >\r
  81 > One thing I noticed which I _think_ is a bug, is that after calling\r
  82 > notmuch-show-resend-message, notmuch-view-raw-message doesn't work\r
  83 > anymore, complaining about a read-only buffer.\r
  84 \r
  85 That is interesting in a sense that I could not reproduce. I think I know\r
  86 exactly why this happens: notmuch-view-raw-message creates read-only buffer\r
  87 which is not removed after message is resent: re-running\r
  88 notmuch-view-raw-message on same message will `get-buffer-create' with\r
  89 same name and pick the old read-only buffer; inserting data to that buffer\r
  90 fails -- just that in my tests (V C-x b RET V) I could not get the same\r
  91 outcome.\r
  92 \r
  93 The simplest change is to change (bury-buffer) with (kill-buffer). The raw\r
  94 message buffer that was used to send should not be interesting; more\r
  95 interesting is the current (same) message in notmuch-show buffer -- and 'V'\r
  96 can be used to re-view the raw message. \r
  97 What could be added is printing the message id of the message resent to\r
  98 *Messages* buffer. This way re-sender can verify what was resent if being\r
  99 unsure. Just that in the case I've used this I have not looked back...\r
 100 \r
 101 So, probably I make applicable RFC patch of this feature...\r
 102 \r
 103 \r
 104 >\r
 105 > d\r
 106 \r
 107 Tomi\r