From 31ee3f4d03363cb9351099cd49ee38e4c9ead75b Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Fri, 13 Sep 2013 09:13:11 +0300 Subject: [PATCH] Re: [PATCH] emacs: show: stop stderr appearing in buffer --- 16/e45a9db4a94424f3718eb7db6e1e406a358b6a | 124 ++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 16/e45a9db4a94424f3718eb7db6e1e406a358b6a diff --git a/16/e45a9db4a94424f3718eb7db6e1e406a358b6a b/16/e45a9db4a94424f3718eb7db6e1e406a358b6a new file mode 100644 index 000000000..11a176a7a --- /dev/null +++ b/16/e45a9db4a94424f3718eb7db6e1e406a358b6a @@ -0,0 +1,124 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 6DC16431FAF + for ; Thu, 12 Sep 2013 23:13:29 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Ub1ZVDkVk9y2 for ; + Thu, 12 Sep 2013 23:13:19 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id 76314431FAE + for ; Thu, 12 Sep 2013 23:13:18 -0700 (PDT) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id 828DF10007D; + Fri, 13 Sep 2013 09:13:11 +0300 (EEST) +From: Tomi Ollila +To: Mark Walters , + David Bremner , notmuch@notmuchmail.org +Subject: Re: [PATCH] emacs: show: stop stderr appearing in buffer +In-Reply-To: <87a9jivya2.fsf@qmul.ac.uk> +References: <1378502198-7980-1-git-send-email-markwalters1009@gmail.com> + <87r4cwojds.fsf@zancas.localnet> <87ppsepeo9.fsf@qmul.ac.uk> + <87ob7yw8a8.fsf@qmul.ac.uk> + <87a9jivya2.fsf@qmul.ac.uk> +User-Agent: Notmuch/0.16+76~ga4151ca (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.13 +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: Fri, 13 Sep 2013 06:13:30 -0000 + +On Thu, Sep 12 2013, Mark Walters wrote: + +> On Thu, 12 Sep 2013, Tomi Ollila wrote: +>> On Thu, Sep 12 2013, Mark Walters wrote: +>> +>>> On Thu, 12 Sep 2013, Tomi Ollila wrote: +>>>>> +>>>>> Yes this is easy. There are several possibilities and I am not sure +>>>>> which is best (some are clearly bad but are worth mentioning anyway). +>>>>> +>>>>> 1) have a single buffer for part errors; this would accumulate stuff and +>>>>> output seems to get interleaved so this is probably useless. + +Actually this option would be better than 4 -- we get some output and we +could test whether this (temporary) solution work. It is also better than +the current when we get output into show buffer. Then -- probably -- +sometime aroung 2017-2018 if we've got enough bug reports an be also +annoyed ourselves about it (and no-one else have sent tolerable patches +to fix it) we revisit some other fixes. + +Simplest would be just create the buffer (like *notmuch Async* ;) and +use that. A bit more complex would be to output the start date of +async operation that is started (and maybe create mechanism to keep +this (these) message buffers to a certain upper size). + + +>>>>> 2) have a buffer for each part viewer as you describe. +>>>>> +>>>>> 3) have a buffer for each part viewer but start its name with a space so +>>>>> it doesn't show up in buffer lists but is findable (maybe) +>>>>> +>>>>> 4) stick with just the temp buffer approach +>>>> +>>>> +>>>> Maybe check whether the temp buffer is empty. if not, use +>>>> (buffer-string) & (notmuch-logged-error) to append the message +>>>> to the *Notmuch errors* buffer... just that notmuch-logged-error +>>>> signals an error which we may not want to do... +>>> +>>> The problem is that the external part viewer is run asynchronously. So +>>> when we get to the decision what to do the buffer has not received any +>>> output yet even when the first thing the viewer does is output +>>> something. +>>> +>>> A further complication is that in some cases the viewer might not +>>> output things until it is closed and that could be arbitrarily later. +>> +>> I may not have understood completely -- but the temp buffer has lifetime... +>> We could store the timestamp when executing function starts and just +>> before the temp buffer is about to be wiped out, do the emptiness check +>> and if not empty use the stored timestamp & current time in the message +>> to be written to aid the human reader who may want to see the message... +> +> The temp buffer is killed as soon as mm-display-external returns which +> is almost instantly as it starts the external viewer asynchronously. The +> sentinel for the external viewer (called when the external viewer exits) +> sees the calling buffer is dead and just drops the error/output. +> +> So it is not really that the error goes into the temp buffer: it just +> doesn't go into the (quite likely still existing) show buffer. + +Ack. It seems I did not (even) read your original commit message >;) + +> +> Best wishes +> +> Mark +> + +Tomi -- 2.26.2