bug#13400: 23.4; overlapping process filter calls

[Noam Postavsky]

Hendrik Tews <hendrik@askra.de> writes:

> thanks for addressing this quite old bug report. I do have some
> comments:

Thanks for still following up even though the reply was so delayed.

>>> - Section "37.9 Receiving Output from Processes" does not list
>>>   process-send-string. How about other blocking I/O functions?
>>
>> In the attached patch, I've added a mention/xref for functions which send
>> data to processes.
>
> How about other blocking I/O functions?  When output is accepted
> inside process-send-string, then it probably is in all potentially
> blocking I/O functions?

As far as I know, all the blocking functions are listed in the Input to
Processes node which I xref'd.

>>> - Same in "37.9.2. Process Filter Functions"
>>
>> This section is repeated twice (I addressed the second instance below).
>
> I mentioned this section twice, because there are _two_
> documentation problems.

Aha, missed that, thanks.

>>> - Same in "37.4 Creating an Asynchronous Process" ,
>>>   process-send-string is neither waiting for input not time
>>>   delay.
>>
>> I don't see any mention of process-send-string in that section, nor how
>> it's relevant to the rest of this report.
>
> Come on, please read that section carefully. "Emacs accepts data
> from the process only while waiting for input or for a time
> delay" in there implies that Emacs is _not_ accepting data during
> process-send-string, because, as I wrote, 

Thanks, it's hard to pick out such details on the Nth time reading the
manual.

>>> - "37.7 Sending Input to Processes" says that filters can run
>>>   inside process-send-string, but it could be clearer about the
>>>   point that this can also happen inside the same filter for the
>>>   same process.
>>
>> I'm not really convinced that is necessary.
>
> It is about a few words making the documentation more precise,
> potentially saving somebody a painful debugging session of
> several hours

I'm just not sure anyone is going to notice such details when it really
matters.  In my experience the manual is more about having something
authoritative to point to when folks ask "why does X happen?".  But I've
added a parenthetical to the patch.

> Adding to the original bug report, I would suggest to restructure
> the documentation, such that there is only one section
> documenting all the functions in which process output could
> arrive and such that all the other sections only refer to that
> section. It should really not be the case that different sections
> make different and sometimes inconsistent statements about the
> same feature.

Yes, hence the xrefs.  See attached updated patch.

0001-Note-that-process-filter-can-be-called-recursively-B.patch
Description: patch