bug#727: compilation-disable-input

[Andrew Hyatt]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> I'm not sure what this is intended to do.  Sending just one EOF  
>>> character to a process creates one EOF if many conditions are met.   
>>> But a second read from the same pty will continue to look for input.
>>> 
>>> The following code:
>>> (when compilation-disable-input
>>> (condition-case nil
>>> (process-send-eof proc)
>>> ;; The process may have exited already.
>>> (error nil)))
>>> 
>>> Causes my grep buffer to start with a ^D (the EOF character that  
>>> process-send-eof sends).  This goofs up the parsing of the lines.
>
>> I can't reproduce this (I don't see any ^D character in grep buffers).
>> Could you send a recipe for reproducing this bug, as well as your system
>> specs?
>
> I remember seeing exactly these kinds of ^D under Mac OS X where
> process-send-eof causes them (either for pipes or for ttys, can't
> remember which).
>
> I even added a workaround for this problem in pcvs.el's
> cvs-parse-process:
>
>   (when (eq system-type 'darwin)
>     ;; Fixup the ^D^H^H inserted at beginning of buffer sometimes on MacOSX
>     ;; because of the call to `process-send-eof'.
>     (save-excursion
>       (goto-char (point-min))
>       (while (re-search-forward "^\\^D+" nil t)
>       (let ((inhibit-read-only t))
>         (delete-region (match-beginning 0) (match-end 0))))))
>
> Not sure if it's related.
>
>
>         Stefan

I can't reproduce this in Emacs 25, on Mac OS X (although, as Yidong
noted, we don't have clear reproducible steps). Due to all that, and as
the original author hasn't replied in the last 7 years. I'm closing this
as unreproducible, but please re-open if it still exists.