[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 28 Dec 2015 23:52:56 -0500
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin)
Stefan Monnier <address@hidden> 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
> 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
> (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'.
> (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.
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.
|[Prev in Thread]
||[Next in Thread]|
- bug#727: compilation-disable-input,
Andrew Hyatt <=