From: Tomi Ollila Date: Thu, 12 Sep 2013 11:49:23 +0000 (+0300) Subject: Re: [PATCH] emacs: show: stop stderr appearing in buffer X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=c4860723e6fe834bc906da11e51e8efef725d2f4;p=notmuch-archives.git Re: [PATCH] emacs: show: stop stderr appearing in buffer --- diff --git a/b8/9db5fb637e894d1554ac3cf3580da59ff0109c b/b8/9db5fb637e894d1554ac3cf3580da59ff0109c new file mode 100644 index 000000000..140b4d013 --- /dev/null +++ b/b8/9db5fb637e894d1554ac3cf3580da59ff0109c @@ -0,0 +1,123 @@ +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 5B3D8431FAF + for ; Thu, 12 Sep 2013 04:49:40 -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 2GXAW6RKsh2c for ; + Thu, 12 Sep 2013 04:49:35 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id 917BF431FAE + for ; Thu, 12 Sep 2013 04:49:35 -0700 (PDT) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id EF927100090; + Thu, 12 Sep 2013 14:49:23 +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: <87ppsepeo9.fsf@qmul.ac.uk> +References: <1378502198-7980-1-git-send-email-markwalters1009@gmail.com> + <87r4cwojds.fsf@zancas.localnet> <87ppsepeo9.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: Thu, 12 Sep 2013 11:49:40 -0000 + +On Thu, Sep 12 2013, Mark Walters wrote: + +> Hi +> +> On Tue, 10 Sep 2013, David Bremner 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 + + +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... + +We could unify to "*Notmuch Messages*" and have more functions to +append data there... somewhat analogous to current *Messages* buffer +just that that one has so much noise... + +Tomi + + +> +> 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 +> _______________________________________________ +> notmuch mailing list +> notmuch@notmuchmail.org +> http://notmuchmail.org/mailman/listinfo/notmuch