>>> With a problem case, not only does read-from-string result in nil, but
>>> python-send-receive results in nil as well. When debugging
>>> python-send-receive in the same fashion, I run into the phenomenon
>>> where accept-process-output always times out and returns nil, even when
>>> given input known to work. Perhaps this is a result of edebug vs.
>>> regular execution?
>>
>> Yes, edebugging with things like accept-process-output is
>> always problematic. I generally resort to sprinkling the code with
>> (message "here var=%S" var).
>>
>>> I seem to recall issues with OS X and ptys; could this be one of them?
>>
>> Could be. Can you try to change process-connection-type to avoid the use of
>> ptys, and see if it helps?
> That had no effect on the behavior. I guess it must actually be
> an issue with the size of the incoming data vs. some buffer size
> in the C code ... does this sound plausible?
It sounds possible, your experiments seem to indicate the boundary could be
1024 bytes.
> I will write up some scripts to incrementally generate and test Python
> attrs and see what the maximum working length is, for lack of any insight
> into the root cause.
Maybe you could add a `message' at the beginning of python-preoutput-filter,
to see what the process filter actually receives. Or maybe even at the
beginning of comint-output-filter.
Stefan
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
