From: Tomi Ollila <tomi.ollila@iki.fi>
To: Mark Walters <markwalters1009@gmail.com>,
 David Bremner <david@tethera.net>,	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>
	<m2vc26p8e4.fsf@guru.guru-group.fi> <87ob7yw8a8.fsf@qmul.ac.uk>
	<m2d2oe1bad.fsf@guru.guru-group.fi> <87a9jivya2.fsf@qmul.ac.uk>
User-Agent: Notmuch/0.16+76~ga4151ca (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
Date: Fri, 13 Sep 2013 09:13:11 +0300
Message-ID: <m2bo3x9rm0.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Thu, Sep 12 2013, Mark Walters <markwalters1009@gmail.com> wrote:

> On Thu, 12 Sep 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:
>> On Thu, Sep 12 2013, Mark Walters <markwalters1009@gmail.com> wrote:
>>
>>> On Thu, 12 Sep 2013, Tomi Ollila <tomi.ollila@iki.fi> 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