> Yes, it's process-send-string.  I talked earlier about how I think
> sit-for and accept-process-output are two primitives that could just
> error when called from within a process filter, because there's no
> possible reasonable use for them, because they lead to recursive
> filters and recursive filters are arguably "unreasonable".

I agree with the sentiment, but it's not realistic given the amount of
existing code which does that, I think (and the amount of work to fix them).
We could have maybe warnings or somesuch to detect those places and start
fixing them, but I think we also need to up our game in terms of the
infrastucture we provide to help write "correct" async code (see
`futur.el` below which exposes my current ideas).

> But process-send-string (without output-acceptance) in a filter
> makes sense.

You mean "non-blocking"?  Yes, we need a non-blocking variant of `process-send-string`.

> I agree, but process-send-string is never blocking, is it?

It is, currently (which is why it can accept process output in the mean time).

> And anyway if we go your 'spawn' or 'run-asap' way, we don't need to
> change process-send-string's output-acceptance semantics at all.

We do, because when that timer triggers, your Emacs will be unresponsive
while `process-send-string` is running (which can take arbitrarily long
if the process is busy doing other things than reading our string).


        Stefan