From: David Edmondson <dme@dme.org>
To: notmuch@notmuchmail.org
Subject: Re: Carbon (macOS) port asks about killing stderr buffer
Date: Wed, 31 Jan 2018 14:54:52 +0000 [thread overview]
Message-ID: <cunzi4uhydf.fsf@dme.org> (raw)
In-Reply-To: <m27evib3ny.fsf@dme.org>
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.
next prev parent reply other threads:[~2018-01-31 14:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 10:32 Carbon (macOS) port asks about killing stderr buffer David Edmondson
2017-10-30 13:32 ` David Edmondson
2018-01-31 14:54 ` David Edmondson [this message]
2018-08-09 20:54 ` [PATCH v1 1/1] emacs: Kill the stderr buffer when an async process completes David Edmondson
2018-08-25 11:59 ` David Edmondson
2018-08-25 14:27 ` Sebastian Schwarz
2018-08-26 11:30 ` David Bremner
2018-08-26 21:16 ` David Edmondson
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=cunzi4uhydf.fsf@dme.org \
--to=dme@dme.org \
--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).