From: Mark Walters <markwalters1009@gmail.com>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH] emacs: show: stop stderr appearing in buffer
In-Reply-To: <87r4cwojds.fsf@zancas.localnet>
References: <1378502198-7980-1-git-send-email-markwalters1009@gmail.com>
	<87r4cwojds.fsf@zancas.localnet>
User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Thu, 12 Sep 2013 10:33:42 +0100
Message-ID: <87ppsepeo9.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list


Hi

On Tue, 10 Sep 2013, David Bremner <david@tethera.net> wrote:
>> Ideally, we would put this output in the notmuch errors buffer but the
>> handler is called asynchronously so we don't know when the output will
>> appear. Thus if we put it straight into the errors buffer it could get
>> interleaved with other errors, otoh we can't easily tell when we
>> have got all the error output so can't wait until the process is complete.
>
> Hi Mark;
>
> I think your patch is OK, but would it be much harder to created a named
> buffer like *notmuch-view-$message-d* ? (using e.g. the code from
> notmuch-show). I might make debugging easier.

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.

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

Also, we could have it togglable with some sort of debug flag. In some
senses 3 is nice but you would probably end up with 10's or even
hundreds of hidden buffers which seems bad. In 2 you see them so you
probably kill them as you go but I think they would be pretty
annoying. A key difference from the accumulated show/search/pick buffers
is that, at some point, you did want to see those buffers.

Since all these approaches are easy to implement it is really up to us
which we want.

Any thoughts?

Mark


>
> Of course those buffers would accumulate, along with show, search and
> pick buffers...
>
> Or we could push this as is, and add some debugging facility later like
> a variable notmuch-view-errors-buffer.
>
> d