41/93e70cd24d8750502ea4456808723d8c73efed

   1 Return-Path: <m.walters@qmul.ac.uk>\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 olra.theworths.org (Postfix) with ESMTP id 54BFA431FAF\r
   6         for <notmuch@notmuchmail.org>; Thu, 12 Sep 2013 08:46:11 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id uHmGw1dnb4Rp for <notmuch@notmuchmail.org>;\r
  17         Thu, 12 Sep 2013 08:46:03 -0700 (PDT)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 2CFCB431FAE\r
  22         for <notmuch@notmuchmail.org>; Thu, 12 Sep 2013 08:46:03 -0700 (PDT)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1VK95i-0003N1-JP; Thu, 12 Sep 2013 16:46:01 +0100\r
  27 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
  28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
  29         (envelope-from <m.walters@qmul.ac.uk>)\r
  30         id 1VK95i-00008j-8g; Thu, 12 Sep 2013 16:45:58 +0100\r
  31 From: Mark Walters <markwalters1009@gmail.com>\r
  32 To: Tomi Ollila <tomi.ollila@iki.fi>, David Bremner <david@tethera.net>,\r
  33         notmuch@notmuchmail.org\r
  34 Subject: Re: [PATCH] emacs: show: stop stderr appearing in buffer\r
  35 In-Reply-To: <m2d2oe1bad.fsf@guru.guru-group.fi>\r
  36 References: <1378502198-7980-1-git-send-email-markwalters1009@gmail.com>\r
  37         <87r4cwojds.fsf@zancas.localnet> <87ppsepeo9.fsf@qmul.ac.uk>\r
  38         <m2vc26p8e4.fsf@guru.guru-group.fi> <87ob7yw8a8.fsf@qmul.ac.uk>\r
  39         <m2d2oe1bad.fsf@guru.guru-group.fi>\r
  40 User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1\r
  41         (x86_64-pc-linux-gnu)\r
  42 Date: Thu, 12 Sep 2013 16:45:57 +0100\r
  43 Message-ID: <87a9jivya2.fsf@qmul.ac.uk>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: text/plain; charset=us-ascii\r
  46 X-Sender-Host-Address: 93.97.24.31\r
  47 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  48 X-QM-Body-MD5: d654062aa0fccf184484c15531f8d1d4 (of first 20000 bytes)\r
  49 X-SpamAssassin-Score: 0.0\r
  50 X-SpamAssassin-SpamBar: /\r
  51 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  52         determine if it is\r
  53         spam. We require at least 5.0 points to mark a message as spam.\r
  54         This message scored 0.0 points. Summary of the scoring: \r
  55         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  56         provider *      (markwalters1009[at]gmail.com)\r
  57         *  0.0 AWL AWL: From: address is in the auto white-list\r
  58 X-QM-Scan-Virus: ClamAV says the message is clean\r
  59 X-BeenThere: notmuch@notmuchmail.org\r
  60 X-Mailman-Version: 2.1.13\r
  61 Precedence: list\r
  62 List-Id: "Use and development of the notmuch mail system."\r
  63         <notmuch.notmuchmail.org>\r
  64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  67 List-Post: <mailto:notmuch@notmuchmail.org>\r
  68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  71 X-List-Received-Date: Thu, 12 Sep 2013 15:46:11 -0000\r
  72 \r
  73 On Thu, 12 Sep 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  74 > On Thu, Sep 12 2013, Mark Walters <markwalters1009@gmail.com> wrote:\r
  75 >\r
  76 >> On Thu, 12 Sep 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  77 >>> On Thu, Sep 12 2013, Mark Walters <markwalters1009@gmail.com> wrote:\r
  78 >>>\r
  79 >>>> Hi\r
  80 >>>>\r
  81 >>>> On Tue, 10 Sep 2013, David Bremner <david@tethera.net> wrote:\r
  82 >>>>>> Ideally, we would put this output in the notmuch errors buffer but the\r
  83 >>>>>> handler is called asynchronously so we don't know when the output will\r
  84 >>>>>> appear. Thus if we put it straight into the errors buffer it could get\r
  85 >>>>>> interleaved with other errors, otoh we can't easily tell when we\r
  86 >>>>>> have got all the error output so can't wait until the process is complete.\r
  87 >>>>>\r
  88 >>>>> Hi Mark;\r
  89 >>>>>\r
  90 >>>>> I think your patch is OK, but would it be much harder to created a named\r
  91 >>>>> buffer like *notmuch-view-$message-d* ? (using e.g. the code from\r
  92 >>>>> notmuch-show). I might make debugging easier.\r
  93 >>>>\r
  94 >>>> Yes this is easy. There are several possibilities and I am not sure\r
  95 >>>> which is best (some are clearly bad but are worth mentioning anyway).\r
  96 >>>>\r
  97 >>>> 1) have a single buffer for part errors; this would accumulate stuff and\r
  98 >>>> output seems to get interleaved so this is probably useless.\r
  99 >>>>\r
 100 >>>> 2) have a buffer for each part viewer as you describe.\r
 101 >>>>\r
 102 >>>> 3) have a buffer for each part viewer but start its name with a space so\r
 103 >>>> it doesn't show up in buffer lists but is findable (maybe)\r
 104 >>>>\r
 105 >>>> 4) stick with just the temp buffer approach\r
 106 >>>\r
 107 >>>\r
 108 >>> Maybe check whether the temp buffer is empty. if not, use\r
 109 >>> (buffer-string) & (notmuch-logged-error) to append the message\r
 110 >>> to the *Notmuch errors* buffer... just that notmuch-logged-error\r
 111 >>> signals an error which we may not want to do...\r
 112 >>\r
 113 >> The problem is that the external part viewer is run asynchronously. So\r
 114 >> when we get to the decision what to do the buffer has not received any\r
 115 >> output yet even when the first thing the viewer does is output\r
 116 >> something.\r
 117 >>\r
 118 >> A further complication is that in some cases the viewer might not\r
 119 >> output things until it is closed and that could be arbitrarily later.\r
 120 >\r
 121 > I may not have understood completely -- but the temp buffer has lifetime...\r
 122 > We could store the timestamp when executing function starts and just\r
 123 > before the temp buffer is about to be wiped out, do the emptiness check\r
 124 > and if not empty use the stored timestamp & current time in the message\r
 125 > to be written to aid the human reader who may want to see the message...\r
 126 \r
 127 The temp buffer is killed as soon as mm-display-external returns which\r
 128 is almost instantly as it starts the external viewer asynchronously. The\r
 129 sentinel for the external viewer (called when the external viewer exits)\r
 130 sees the calling buffer is dead and just drops the error/output.\r
 131 \r
 132 So it is not really that the error goes into the temp buffer: it just\r
 133 doesn't go into the (quite likely still existing) show buffer.\r
 134 \r
 135 Best wishes\r
 136 \r
 137 Mark\r
 138 \r
 139 \r
 140 \r
 141 \r
 142 \r
 143 >\r
 144 >>\r
 145 >> Best wishes\r
 146 >>\r
 147 >> Mark\r
 148 >\r
 149 > Tomi\r
 150 >\r
 151 >\r
 152 >>\r
 153 >>\r
 154 >>>\r
 155 >>> We could unify to "*Notmuch Messages*" and have more functions to \r
 156 >>> append data there... somewhat analogous to current *Messages* buffer\r
 157 >>> just that that one has so much noise...\r
 158 >>>\r
 159 >>> Tomi\r
 160 >>>\r
 161 >>>\r
 162 >>>>\r
 163 >>>> Also, we could have it togglable with some sort of debug flag. In some\r
 164 >>>> senses 3 is nice but you would probably end up with 10's or even\r
 165 >>>> hundreds of hidden buffers which seems bad. In 2 you see them so you\r
 166 >>>> probably kill them as you go but I think they would be pretty\r
 167 >>>> annoying. A key difference from the accumulated show/search/pick buffers\r
 168 >>>> is that, at some point, you did want to see those buffers.\r
 169 >>>>\r
 170 >>>> Since all these approaches are easy to implement it is really up to us\r
 171 >>>> which we want.\r
 172 >>>>\r
 173 >>>> Any thoughts?\r
 174 >>>>\r
 175 >>>> Mark\r
 176 >>>>\r
 177 >>>>\r
 178 >>>>>\r
 179 >>>>> Of course those buffers would accumulate, along with show, search and\r
 180 >>>>> pick buffers...\r
 181 >>>>>\r
 182 >>>>> Or we could push this as is, and add some debugging facility later like\r
 183 >>>>> a variable notmuch-view-errors-buffer.\r
 184 >>>>>\r
 185 >>>>> d\r
 186 >>>> _______________________________________________\r
 187 >>>> notmuch mailing list\r
 188 >>>> notmuch@notmuchmail.org\r
 189 >>>> http://notmuchmail.org/mailman/listinfo/notmuch\r
 190 >> _______________________________________________\r
 191 >> notmuch mailing list\r
 192 >> notmuch@notmuchmail.org\r
 193 >> http://notmuchmail.org/mailman/listinfo/notmuch\r