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
Date: Fri, 13 Sep 2013 09:13:11 +0300 [thread overview]
Message-ID: <m2bo3x9rm0.fsf@guru.guru-group.fi> (raw)
In-Reply-To: <87a9jivya2.fsf@qmul.ac.uk>
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
next prev parent reply other threads:[~2013-09-13 6:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 21:16 [PATCH] emacs: show: stop stderr appearing in buffer Mark Walters
2013-09-10 14:12 ` David Bremner
2013-09-12 9:33 ` Mark Walters
2013-09-12 10:56 ` David Bremner
2013-09-12 11:49 ` Tomi Ollila
2013-09-12 12:09 ` Mark Walters
2013-09-12 12:20 ` Tomi Ollila
2013-09-12 15:45 ` Mark Walters
2013-09-13 6:13 ` Tomi Ollila [this message]
2013-09-12 14:53 ` Austin Clements
2013-09-12 15:43 ` Mark Walters
-- strict thread matches above, loose matches on Subject: below --
2013-11-13 9:03 Mark Walters
2013-11-13 21:58 ` Tomi Ollila
2013-11-18 11:35 ` David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2bo3x9rm0.fsf@guru.guru-group.fi \
--to=tomi.ollila@iki.fi \
--cc=david@tethera.net \
--cc=markwalters1009@gmail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).