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 D2C90431FAF
\r
6 for <notmuch@notmuchmail.org>; Thu, 12 Sep 2013 08:43:42 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\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 CvZerD1jMom6 for <notmuch@notmuchmail.org>;
\r
17 Thu, 12 Sep 2013 08:43:37 -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 6581F431FAE
\r
22 for <notmuch@notmuchmail.org>; Thu, 12 Sep 2013 08:43:37 -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 1VK93K-0001Sf-WD; Thu, 12 Sep 2013 16:43:31 +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 1VK93K-0007e2-FU; Thu, 12 Sep 2013 16:43:30 +0100
\r
31 From: Mark Walters <markwalters1009@gmail.com>
\r
32 To: Austin Clements <amdragon@MIT.EDU>
\r
33 Subject: Re: [PATCH] emacs: show: stop stderr appearing in buffer
\r
34 In-Reply-To: <20130912145326.GK1426@mit.edu>
\r
35 References: <1378502198-7980-1-git-send-email-markwalters1009@gmail.com>
\r
36 <87r4cwojds.fsf@zancas.localnet> <87ppsepeo9.fsf@qmul.ac.uk>
\r
37 <20130912145326.GK1426@mit.edu>
\r
38 User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1
\r
39 (x86_64-pc-linux-gnu)
\r
40 Date: Thu, 12 Sep 2013 16:43:28 +0100
\r
41 Message-ID: <87eh8uvye7.fsf@qmul.ac.uk>
\r
43 Content-Type: text/plain; charset=us-ascii
\r
44 X-Sender-Host-Address: 93.97.24.31
\r
45 X-QM-SPAM-Info: Sender has good ham record. :)
\r
46 X-QM-Body-MD5: ff2160dedb053a103ec74db3cc140a9f (of first 20000 bytes)
\r
47 X-SpamAssassin-Score: 0.0
\r
48 X-SpamAssassin-SpamBar: /
\r
49 X-SpamAssassin-Report: The QM spam filters have analysed this message to
\r
51 spam. We require at least 5.0 points to mark a message as spam.
\r
52 This message scored 0.0 points. Summary of the scoring:
\r
53 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
\r
54 provider * (markwalters1009[at]gmail.com)
\r
55 * 0.0 AWL AWL: From: address is in the auto white-list
\r
56 X-QM-Scan-Virus: ClamAV says the message is clean
\r
57 Cc: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
\r
58 X-BeenThere: notmuch@notmuchmail.org
\r
59 X-Mailman-Version: 2.1.13
\r
61 List-Id: "Use and development of the notmuch mail system."
\r
62 <notmuch.notmuchmail.org>
\r
63 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
64 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
65 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
66 List-Post: <mailto:notmuch@notmuchmail.org>
\r
67 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
68 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
69 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
70 X-List-Received-Date: Thu, 12 Sep 2013 15:43:43 -0000
\r
72 On Thu, 12 Sep 2013, Austin Clements <amdragon@MIT.EDU> wrote:
\r
73 > Quoth Mark Walters on Sep 12 at 10:33 am:
\r
77 >> On Tue, 10 Sep 2013, David Bremner <david@tethera.net> wrote:
\r
78 >> >> Ideally, we would put this output in the notmuch errors buffer but the
\r
79 >> >> handler is called asynchronously so we don't know when the output will
\r
80 >> >> appear. Thus if we put it straight into the errors buffer it could get
\r
81 >> >> interleaved with other errors, otoh we can't easily tell when we
\r
82 >> >> have got all the error output so can't wait until the process is complete.
\r
86 >> > I think your patch is OK, but would it be much harder to created a named
\r
87 >> > buffer like *notmuch-view-$message-d* ? (using e.g. the code from
\r
88 >> > notmuch-show). I might make debugging easier.
\r
90 >> Yes this is easy. There are several possibilities and I am not sure
\r
91 >> which is best (some are clearly bad but are worth mentioning anyway).
\r
93 >> 1) have a single buffer for part errors; this would accumulate stuff and
\r
94 >> output seems to get interleaved so this is probably useless.
\r
96 >> 2) have a buffer for each part viewer as you describe.
\r
98 >> 3) have a buffer for each part viewer but start its name with a space so
\r
99 >> it doesn't show up in buffer lists but is findable (maybe)
\r
101 > 3.5) Say something in the echo area when a viewer terminates with
\r
102 > output, so it doesn't interrupt the user if they're doing something,
\r
103 > but the output buffer is still discoverable. Maybe bind C-c ` to show
\r
104 > the most recently reported output buffer, like what (la)tex-mode and
\r
105 > others do, and mention this binding in the echo area message.
\r
107 The key problem here is that I don't know how to tell when the viewer
\r
108 terminates. The viewer is run asynchronously and the sentinel for that
\r
109 process puts the output in the buffer that called mm-display-external
\r
110 (provided that that buffer is still alive).
\r
112 Moreover, the code in mm-display-external seems to do some strange point
\r
115 (when (buffer-live-p outbuf)
\r
116 (with-current-buffer outbuf
\r
117 (let ((buffer-read-only nil)
\r
121 handle (with-current-buffer buffer
\r
123 (goto-char point))))
\r
125 which seems to put this batch of error/output into the buffer two lines
\r
126 into the previous batch of error/output.
\r
129 >> 4) stick with just the temp buffer approach
\r
131 >> Also, we could have it togglable with some sort of debug flag. In some
\r
132 >> senses 3 is nice but you would probably end up with 10's or even
\r
133 >> hundreds of hidden buffers which seems bad. In 2 you see them so you
\r
134 >> probably kill them as you go but I think they would be pretty
\r
135 >> annoying. A key difference from the accumulated show/search/pick buffers
\r
136 >> is that, at some point, you did want to see those buffers.
\r
138 > 3.5.1) Don't create a buffer until the command has output (or, easier
\r
139 > to implement: create the buffer, but kill it on exit if there was no
\r
140 > output). When starting a new command, kill output buffers from
\r
141 > no-longer-running viewers that have never been visited (using
\r
142 > buffer-display-count or buffer-display-time).
\r
144 Again this relies on being able to tell when a viewer has finished. If I
\r
145 can do that then I think I could just put the output as a block in
\r
152 >> Since all these approaches are easy to implement it is really up to us
\r
161 >> > Of course those buffers would accumulate, along with show, search and
\r
162 >> > pick buffers...
\r
164 >> > Or we could push this as is, and add some debugging facility later like
\r
165 >> > a variable notmuch-view-errors-buffer.
\r