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