Re: proxy icon and moved files
On Wed, 23 Aug 2006 12:53:12 +0100, David Reitter [EMAIL PROTECTED] said: The proxy icon is set by giving the corresponding alias record to SetWindowProxyAlias. But the correspondence between file name and alias record seems to be not persistent. Actually, the latter takes care of renaming. So if you keep alias records, then you refer to the files by FSRef, correct? I'm not sure, but maybe not. Technical Note TN2078 says: Like FSSpecs, FSRefs are not guaranteed to be valid across boots in Mac OS 9 or Mac OS X, across processes in Mac OS X, or even across separate launches of the same application in Mac OS X, so don't use them when you need persistent storage. For persistent storage, aliases are still the recommended approach. (http://developer.apple.com/technotes/tn2002/tn2078.html) Could standard tracking of file changes (e.g. user changes file name or moves the file in Finder, Emacs updates its records automatically) then be easily implemented? Yes. You can see the value that the variable `alias' is bound to tracks the renamed file in the following code: (let* ((file1 (make-temp-file foo)) (file2 (concat file1 -renamed)) (alias (mac-coerce-ae-data 'undecoded-file-name (encode-coding-string file1 'utf-8) alis))) (rename-file file1 file2) (prog1 (decode-coding-string (mac-coerce-ae-data alis alias 'undecoded-file-name) 'utf-8) (delete-file file2))) Could you try the following patch? It tries to see if the alias record that is currently set is updated by the current file name. I tried it and it seems to work - I can't reproduce the problem anymore. Thanks for testing. I've installed the change. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Key descriptions in *Help* are too wide
Kim's suggestion is the best, for after the release: let a ... button call `where-is' to display all the bindings. Richard's suggestion could be added to that: indicate how many more are not shown: foo, bar,... (3 more). Before the release, it would be sufficient to cut off the list at a reasonable number of bindings or max number of columns: either stop when the max width is reached or fill the text up to that reasonable number of bindings - and then append After the release, the ... could be made into a button that calls `where-is' on the command. Would someone please implement one of these? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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 any reason not to use them? Or at least try them first? If delete-process does not work on Cygwin, that is a bug. Instead of proposing workarounds to avoid calling it, how about debugging it and fixing it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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'
That is because you are using sh escape syntax in cmd.exe. Removing the
backslash characters works in general, because the characters they are
escaping do not have special meaning in cmd.exe. For those characters
that do have special meaning, I think doubling them escapes them in cmd.exe
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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-process' works instead. Is there any reason not to use them? Or at least try them first? If delete-process does not work on Cygwin, that is a bug. Instead of proposing workarounds to avoid calling it, how about debugging it and fixing it? 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 to do. IMO this is a bit inconvenient, but it could perhaps still be the best. But it works quite nicely AFICT with sending signals to Cygwin instead using interrupt-process or kill-process. So why not try these first and then shoot with delete-process if they do not work within a couple of seconds? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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: missing argument to `-exec'
That is because you are using sh escape syntax in cmd.exe. Removing
the backslash characters works in general, because the characters they
are escaping do not have special meaning in cmd.exe. For those
characters that do have special meaning, I think doubling them escapes
them in cmd.exe
Yes, I guess that is the trouble, but me? I did not write
find-grep-dired ;-)
Since you understand this much better than me could you perhaps try
fixing the command used by find-grep-dired?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process - bug in shell-quote-argument?
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 -ld
{} \;
find: missing argument to `-exec'
That is because you are using sh escape syntax in cmd.exe. Removing
the backslash characters works in general, because the characters
they are escaping do not have special meaning in cmd.exe. For those
characters that do have special meaning, I think doubling them
escapes them in cmd.exe
Yes, I guess that is the trouble, but me? I did not write
find-grep-dired ;-)
Since you understand this much better than me could you perhaps try
fixing the command used by find-grep-dired?
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?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process - bug in shell-quote-argument?
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 complete implementation of what should be done for Windows native shells. But it doesn't explain why you are getting sh style quoting on w32 without making changes to that function. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process - bug in shell-quote-argument?
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-dos has a much more complete implementation of what
should be done for Windows native shells. But it doesn't explain why
you are getting sh style quoting on w32 without making changes to that
function.
No, there seems to be several bugs here. I wonder whether there is
inconsistent use of shell-quote-argument?
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 argument to `-exec'
Stepping through shell-quote-argument it I can see that it tales the
'windows-nt path so that should be ok. There is only one call to
shell-quote-argument involved and that is from find-grep-dired.
How should the above command look in this case? I am not very familiar
with find. Perhaps is it not possible to give this command with CMD.EXE?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process - bug in shell-quote-argument?
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 argument to `-exec'
Stepping through shell-quote-argument it I can see that it tales the
'windows-nt path so that should be ok. There is only one call to
shell-quote-argument involved and that is from find-grep-dired.
How should the above command look in this case? I am not very familiar
with find. Perhaps is it not possible to give this command with CMD.EXE?
I haven't tried it myself, but I think the following will work with
cmd.exe and a native port of GNU find:
find . ( -type f -exec grep -q -e message {} ; ) -exec ls -ld {} ;
The problem appears to be that although the string to pass to grep is
passed to shell-quote-argument, other parts of the expression have
hard-coded backslashes. However, passing them to shell-quote-argument
will introduce extra double-quotes on Windows, and I am not sure whether
that will work or not.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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 `delete-process'. Using `interrupt-process' or kill-process' works instead. Is there any reason not to use them? Or at least try them first? If delete-process does not work on Cygwin, that is a bug. Instead of proposing workarounds to avoid calling it, how about debugging it and fixing it? 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 to do. AFAICS, delete-process invokes kill-process to kill the process; the rest of delete-process is just book-keeping. IIUC you say kill-process works (or is it only interrupt_process which works?) instead of delete-process ? But kill-process on cygwin should just invoke cygwin kernel's kill so why does the cygwin code use the w32 message interface? -- or am I missing something. IMO this is a bit inconvenient, but it could perhaps still be the best. But it works quite nicely AFICT with sending signals to Cygwin instead using interrupt-process or kill-process. So why not try these first and then shoot with delete-process if they do not work within a couple of seconds? AFAICS, delete-process calls kill-process, so it looks like a loop in some of the book-keeping in delete-process ... can you find that loop? IOW, what is emacs doing when it hangs ? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: On Cygwin: bootstrap hangs when compiling lisp files...
After getting to the point of doing bt, as shown earlier, and doingtwo finish, I got this message: (gdb) finishRun till exit from #0 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dllWarning:Cannot insert breakpoint 0.Error accessing memory address 0x5: Input/Output error. It makes sense because frame #2 as shown in last email has this address of 0x5. At this point finish will give the same message. So I am stuck there. On 8/10/06, Eli Zaretskii [EMAIL PROTECTED] wrote: Date: Thu, 10 Aug 2006 09:30:06 -0400 From: Ping Liang [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org [Switching to thread 3340.0xe18] (gdb) bt #00x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10x7c9507a8 in ntdll!KiIntSystemCall ()from /cygdrive/c/WINDOWS/system32/ntdll.dll #20x0005 in ?? () #30x0004 in ?? () #40x0001 in ?? () #50x1873ffd0 in ?? () #60x0246 in ?? () #70x in ?? () #80x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll #90x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? () (gdb)Thanks.This shows that Emacs was in a system call when youstopped it.You should now use the technique described in etc/DEBUG to find out where it is looping.Search for the section in DEBUGnamed If the symptom of the bug is that Emacs fails to respond, anduse the `finish' command as described there to find out where in the Emacs sources it loops. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process
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 what to do. AFAICS, delete-process invokes kill-process to kill the process; the rest of delete-process is just book-keeping. IIUC you say kill-process works (or is it only interrupt_process which works?) instead of delete-process ? But kill-process on cygwin should just invoke cygwin kernel's kill so why does the cygwin code use the w32 message interface? -- or am I missing something. At the moment I am very confused about what actually happened. I was testing another software firewall, but since things went very slow with I switched back to my old software firewall. After that I tested again and I was going to say that the problem is gone. It is nearly - but not quite. Most of the times kill-find works now, but once Emacs froze like before. Could this be some kind of race condition? It could be problems with my PC. There is something wrong I think, but I have not been able to find out what. At the moment I do not know what to test and I do not understand how to read the C code. How do I know the values of the different constants used by ifdef? I began writing something that would let me know that, but I did not quite finish it. AFAICS, delete-process calls kill-process, so it looks like a loop in some of the book-keeping in delete-process ... can you find that loop? IOW, what is emacs doing when it hangs ? It does not look like a loop. Emacs eats no CPU. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't stop find-grep-dired when using Cygwin for the inferior process - bug in shell-quote-argument?
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 {} \;
find: missing argument to `-exec'
Stepping through shell-quote-argument it I can see that it tales the
'windows-nt path so that should be ok. There is only one call to
shell-quote-argument involved and that is from find-grep-dired.
How should the above command look in this case? I am not very
familiar with find. Perhaps is it not possible to give this command
with CMD.EXE?
I haven't tried it myself, but I think the following will work with
cmd.exe and a native port of GNU find:
find . ( -type f -exec grep -q -e message {} ; ) -exec ls -ld {} ;
The problem appears to be that although the string to pass to grep is
passed to shell-quote-argument, other parts of the expression have
hard-coded backslashes. However, passing them to shell-quote-argument
will introduce extra double-quotes on Windows, and I am not sure
whether that will work or not.
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-characters that will quote characters
like (); if it is a unix style shell.
2) A new function w32-shell-is-unix-style that looks at shell-file-name.
3) A new variable w32-unix-style-shells that have a list of regexps for
the function in 2 to use for matching shell-file-name
4) Use 2 in 1 and in shell-quote-argument
How about this approach?
BTW the doc string for find-grep-dired is incorrect in several ways.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
