I think it is the wrong fix to just ignore an error which should not
occur in the first place. Rather process-send-eof should be fixed not
to throw an error as long as the process is not considered dead from
Emacs' point of view. That there is nobody to actually look at the
eo
>> + (when compilation-disable-input
>> +(condition-case nil
>> +(process-send-eof proc)
>> + ;; The process may have exited already.
>> + (error nil)))
>> (setq compilation-in-progress
>> (cons proc compilation-in-progr
Stefan Monnier <[EMAIL PROTECTED]> writes:
`compilation-start' needs to check if the process is running
before calling `process-send-eof':
>>>
>>> That's odd. AFAICT no blobking operation takes place between the
>>> start-process and the process-send-eof, so the process-status should s
>>> `compilation-start' needs to check if the process is running
>>> before calling `process-send-eof':
>>
>> That's odd. AFAICT no blobking operation takes place between the
>> start-process and the process-send-eof, so the process-status should still
>> be `run' no matter how quickly the proces
>> `compilation-start' needs to check if the process is running
>> before calling `process-send-eof':
>
> That's odd. AFAICT no blobking operation takes place between the
> start-process and the process-send-eof, so the process-status should still
> be `run' no matter how quickly the process exits
> With this change, when grep finishes too quickly (for example, after
> searching in a nonexistent file), `process-send-eof' fails with the
> following error:
> Debugger entered--Lisp error: (error "Process grep not running")
> process-send-eof(#)
> compilation-start("grep -inH -e search file
`compilation-start' needs to check if the process is running
before calling `process-send-eof':
Please install your patch--and thanks.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
>> Thanks for posting the URL, though it seems that the web interface at
>> lists.gnu.org eats multiple spaces. Here is the Gmane URL for the
>> original post from Kevin Rodgers with correct indentation:
>>
>>http://article.gmane.org/gmane.emacs.devel/33146
>>
>> Can someone
> On Sat, 20 Aug 2005 15:22:41 +0300, Eli Zaretskii <[EMAIL PROTECTED]>
> said:
>> Thanks for posting the URL, though it seems that the web interface
>> at lists.gnu.org eats multiple spaces. Here is the Gmane URL for
>> the original post from Kevin Rodgers with correct indentation:
>>
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> Date: Wed, 17 Aug 2005 02:25:39 -0400
> Cc: emacs-devel@gnu.org
>
> Thanks for posting the URL, though it seems that the web interface at
> lists.gnu.org eats multiple spaces. Here is the Gmane URL for the
> original post from Kevin
Thanks for posting the URL, though it seems that the web interface at
lists.gnu.org eats multiple spaces. Here is the Gmane URL for the
original post from Kevin Rodgers with correct indentation:
http://article.gmane.org/gmane.emacs.devel/33146
Can someone please install it?
Karl Chen writes:
> Kevin Rodgers posted a patch that would allow `grep' to close stdin,
> solving this annoyance, but it appears it was never followed up.
> http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00452.html
Yes, that's exactly what David Kastrup suggested in another reply.
Th
hat Kevin
Rodgers already posted such a patch to this list. Here is the URL:
http://article.gmane.org/gmane.emacs.devel/33146
I'll try his patch out.
> grep-use-null-device is just for getting file names on matches, not
> for dealing with bad commands.
That was my confusion. It sav
> On 2005-08-15 19:25 PDT, Richard M Stallman writes:
rms> So, my grep program supports "-H" but it apparently
rms> has not the expected semantics.
rms> That is a very vague statement. It tells us nothing.
Emilio is reiterating the same issue I raised on 2005-02-03 [1]:
> If the user forgets to provide a filename to "M-x grep" (as in
> "grep -nH foo") it will run indefinitely waiting for input from
> stdin until killed. In such cases it's useful to have `null-device'
> appended, even if the grep program supports the option "-H" (which
> has an other purpose anywa
d be done is that standard input on the grep
process gets closed. That requires no special options, and it will
lead to a sensible result without obscure extra options.
grep-use-null-device is just for getting file names on matches, not
for dealing with bad commands.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Emilio Lopes writes:
> As a result, if I forget to provide a filename to "M-x grep" it will
> run forever, waiting for me to kill it.
Richard M Stallman writes:
> So, my grep program supports "-H" but it apparently has not the
> expected semantics.
> That is a very vague statement. It
So, my grep program supports "-H" but it apparently has not the
expected semantics.
That is a very vague statement. It tells us nothing. Why don't you
tell us what DOES happen, instead of just saying you think it is wrong
somehow.
Please read the Bugs section in the Emacs manual, which
The documentation of this variable says:
grep-use-null-device's value is nil
If t, append the value of `null-device' to `grep' commands.
This is done to ensure that the output of grep includes the filename of
any match in the case where only a single file is searched, and is not
ne
19 matches
Mail list logo
