[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#727: compilation-disable-input

From: Andrew Hyatt
Subject: bug#727: compilation-disable-input
Date: Mon, 28 Dec 2015 23:52:56 -0500
User-agent: 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
>> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]