Lennart Borgman wrote:
Andreas Schwab wrote:
Richard Stallman <[EMAIL PROTECTED]> writes:
I see C-c C-k already has that meaning in the buffers made by M-x grep
and M-x compile. So let's set it up to kill the process of
find-grep-dired as well.
It already does.
Andreas.
Thanks. I
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Lennart Borgman wrote:
>> Andreas Schwab wrote:
>>> Richard Stallman <[EMAIL PROTECTED]> writes:
>>>
>>>
I see C-c C-k already has that meaning in the buffers made by M-x grep
and M-x compile. So let's set it up to kill the process of
Kim F. Storm wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
Lennart Borgman wrote:
Andreas Schwab wrote:
Richard Stallman <[EMAIL PROTECTED]> writes:
I see C-c C-k already has that meaning in the buffers made by M-x grep
and M-x compile. So let's set it up to
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Kim F. Storm wrote:
>> Lennart Borgman <[EMAIL PROTECTED]> writes:
>>
>>
>>> Lennart Borgman wrote:
>>>
Andreas Schwab wrote:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>
>> I see C-c C-k already
Kim F. Storm wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
Kim F. Storm wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
Lennart Borgman wrote:
Andreas Schwab wrote:
Richard Stallman <[EMAIL PROTECTED]> writes:
>> Thanks. I did not notice and now I know why. When using Cygwin for
>> the inferior process trying to use kill-find just hangs Emacs. So
>> there is a bug here.
>>
>> kill-find now uses `delete-process'. Using `interrupt-process' or
>> kill-process' works instead. Is there
Lennart Borgman wrote:
There seem to be another bug on w32 too. I just tried using CMD.EXE
for the inferior process instead. That does not seem to work at all. I
got this:
d:/ecvs/:
find . \( -type f -exec grep -q -e "message" {} \; \) -exec ls -ld
{} \;
find: missing argument to `-exec'
Richard Stallman wrote:
>> Thanks. I did not notice and now I know why. When using Cygwin for
>> the inferior process trying to use kill-find just hangs Emacs. So
>> there is a bug here.
>>
>> kill-find now uses `delete-process'. Using `interrupt-process' or
>> kill-proces
Jason Rumney wrote:
Lennart Borgman wrote:
There seem to be another bug on w32 too. I just tried using CMD.EXE
for the inferior process instead. That does not seem to work at all.
I got this:
d:/ecvs/:
find . \( -type f -exec grep -q -e "message" {} \; \) -exec ls -ld
{} \;
find: missin
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Richard Stallman wrote:
>> >> Thanks. I did not notice and now I know why. When using Cygwin for
>> >> the inferior process trying to use kill-find just hangs Emacs. So
>> >> there is a bug here.
>> >>
>> >> kill-find now uses `dele
Kim F. Storm wrote:
The problem on w32 is that w32 sends a message to the process when
delete-process is used. W32 then expects the process to answer to some
w32 message (can't remember which one right now). Cygwin does not
answer to this message. Then w32 shows a dialog box and asks the user
wha
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Kim F. Storm wrote:
>>> The problem on w32 is that w32 sends a message to the process when
>>> delete-process is used. W32 then expects the process to answer to some
>>> w32 message (can't remember which one right now). Cygwin does not
>>> answer to th
The problem on w32 is that w32 sends a message to the process when
delete-process is used. W32 then expects the process to answer to some
w32 message (can't remember which one right now). Cygwin does not answer
to this message. Then w32 shows a dialog box and asks the user what t
Kim F. Storm wrote:
How can the choice of firewall influence whether delete-process
works or not?
I do not know. I just know that when I reverted to my old firewall the
problem seems to be (nearly) gone. And I know that with the other
firewall things sometimes slowed down to a crawl.
I am
Lennart Borgman <[EMAIL PROTECTED]> writes:
>> It is probably waiting for some event then. A backtrace
>> should show you where it is waiting, and the state may
>> then show you what it is waiting for.
>>
> Is there any way to get that when Emacs is frozen?
Run it in a debugger, and stop it w
Lennart Borgman wrote:
Jason Rumney wrote:
Lennart Borgman wrote:
There seem to be another bug on w32 too. I just tried using CMD.EXE
for the inferior process instead. That does not seem to work at all.
I got this:
d:/ecvs/:
find . \( -type f -exec grep -q -e "message" {} \; \) -exec ls -
Lennart Borgman wrote:
I think there is a bug in shell-quote-argument that is used here. This
function does not care about shell-file-name. How can quoting succeed
if it does not do that?
Indeed, that is a problem, as is the blind wrapping in double quotes on
w32 when ms-dos has a much more c
Jason Rumney wrote:
Lennart Borgman wrote:
I think there is a bug in shell-quote-argument that is used here.
This function does not care about shell-file-name. How can quoting
succeed if it does not do that?
Indeed, that is a problem, as is the blind wrapping in double quotes
on w32 when ms-
Lennart Borgman wrote:
In any case the command string that is built and send to CMD does not
work. Here I am using the GnuWin32 port of find, version 4.2.20. Find
complains about the first -exec:
find . \( -type f -exec grep -q -e "message" {} \; \) -exec ls -ld
{} \;
find: missing ar
Jason Rumney wrote:
Lennart Borgman wrote:
In any case the command string that is built and send to CMD does not
work. Here I am using the GnuWin32 port of find, version 4.2.20. Find
complains about the first -exec:
find . \( -type f -exec grep -q -e "message" {} \; \) -exec ls
-ld {} \;
Lennart Borgman <[EMAIL PROTECTED]> writes:
>> find . ( -type f -exec grep -q -e "message" {} ; ) -exec ls -ld {} ;
>
> Thanks, that expression works with the GnuWin32 port of GNU find and
> CMD.exe.
>
> To remove the bugs I suggest the following approach:
>
> 1) A new function quote-special-chara
Lennart Borgman wrote:
1) A new function quote-special-characters that will quote characters
like (); if it is a unix style shell.
If we DTRT in shell-quote-argument, then we don't need to introduce
further complication.
2) A new function w32-shell-is-unix-style that looks at shell-file-nam
Jason Rumney wrote:
We already have w32-system-shells, which is the inverse of the
variable you propose (except it is missing "cmdproxy.exe", I am not
sure if there is a good reason for that).
In fact we have a function w32-shell-dos-semantics for precisely this
purpose. So a suitable patch mig
Jason Rumney wrote:
Jason Rumney wrote:
We already have w32-system-shells, which is the inverse of the
variable you propose (except it is missing "cmdproxy.exe", I am not
sure if there is a good reason for that).
In fact we have a function w32-shell-dos-semantics for precisely this
purpose. So
> Date: Mon, 28 Aug 2006 15:37:02 +0100
> From: Jason Rumney <[EMAIL PROTECTED]>
> Cc: "Kim F. Storm" <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org
>
> The only thing left is to silence the compiler warning about
> w32-shell-dos-semantics not being defined on other platforms. Is
> (defun w32-shel
> Date: Mon, 28 Aug 2006 18:09:19 +0200
> From: Lennart Borgman <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, "Kim F. Storm" <[EMAIL PROTECTED]>
>
> - Is there not a unix style shell for DOS too?
Yes, there's a DOS port of Bash. However, the users of the DOS port
of Emacs (if there still
26 matches
Mail list logo
