On Thursday, 2017-10-26 at 12:32:17 +0100, David Edmondson wrote: > After the changes to use `make-process', the Carbon port of emacs on > macOS (often referred to as emacs-mac or the railwaycat port) will ask > about killing the stderr buffer after any `notmuch-search': > > Debugger entered--Lisp error: (quit) > yes-or-no-p("Buffer \" *notmuch-stderr*-839121\" has a running process; kill it? ") > process-kill-buffer-query-function() > kill-buffer(#<buffer *notmuch-stderr*-839121>) > notmuch-start-notmuch-sentinel(#<process notmuch-search> "finished\n") This happens on the current version of OpenIndiana (a fork of a fork of a fork of a fork of Solaris) as well when running: (emacs-version) "GNU Emacs 25.3.1 (i386-pc-solaris2.11, GTK+ Version 2.24.31) of 2017-09-12" > A quick look at the implementation of `make-process' in the Carbon port > didn't reveal anything obvious to me. This mostly seems like a race - > whether emacs has decided that the process associated with the stderr > buffer is dead or not when we call `kill-buffer'. Is any ordering > guaranteed by the implementation? > > I _think_ that have also seen the same problem when asynchronous address > harvesting is happening for completion on the default NextStep port for > macOS, but haven't been able to reliably reproduce it. > > dme. > -- > I got a girlfriend that's better than that. dme. -- So think of Bob and Judy, they're happy as can be. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch