bug#12579: Emacs 24.2 crashes or freezes

["Fabrice Niessen" <fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org>]

Hi Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org>
>> "Fabrice Niessen" wrote:
>> > Eli Zaretskii wrote:
>> >> Can you kill it from Process Explorer (by pressing Del)?  If you can,
>> >> does Emacs get out of the lockup?
>> >
>> > Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
>> > see on
>> > http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
>> > I just recovered where I was, in Helm, with the correct files show now -- I
>> > had previously typed more characters in the pattern, when Emacs just froze...
>> > Now, they reappeared, with correct results from the "locate" command.
>> >
>> > Great news, I guess, in the understanding of what happens...
>>
>> Did you see this?  Does it tell you something more?
>
> I did see it, but I'm waiting for your report on using es.exe from
> cmdproxy.

After many days of intensive Emacs use, I can tell that Everything does not
block Emacs anymore, when

    (setq shell-file-name "cmdproxy") [1]

So, thanks to that (and to you), I don't have big problems anymore. GREAT.

Though, I inherit other problems due to bad handling of miscellaneous styles
of directory separator in the full filenames: among others, I now have
troubles launching my PDF viewer from AUCTeX.

The displayed command for the View action is:

    "C:\Program Files/SumatraPDF/SumatraPDF.exe" "ecm.pdf"

When `shell-file-name' is `bash', SumatraPDF is launched normally.

When `shell-file-name' is `cmdproxy', nothing happens. Really nothing, btw:
not even a message in the echo area, nor in the Messages buffer. Same
behavior for `cmd'. No PDF viewer.

Okay, I admit the above command is a bit (or more?) awkward due to the mix of
slashes and (unescaped) backslashes. But this used to work before, and I'm
fearing to loose such working behaviors by fully switching from `bash' to
`cmdproxy'[2].

Why is the command that specially written? Because I tried to abstract the
definition of the localization of SumatraPDF so that it can work on my PC
(32-bit Win XP) and on my colleagues' PC (64-bit Win 7), automatically finding
out the correct path between `c:\Program Files' and potential differences
(`c:\Program Files (x86)' or some such differences in the future), by having:

--8<---------------cut here---------------start------------->8---
  (defconst windows-program-files-dir
    (concat (getenv "PROGRAMFILES") "/")
    "Defines the default Windows Program Files folder.")

  (defvar sumatrapdf-command
    (concat windows-program-files-dir "SumatraPDF/SumatraPDF.exe")
    "Path to the SumatraPDF executable.")
--8<---------------cut here---------------end--------------->8---

Is it that bad?

Hence, 2 questions:

- Is using `cmdproxy' really the only way to handle properly the communication
  between Emacs and Everything?

- I see (in Process Explorer) that `cmdproxy' launches a `cmd' process: why
  not directly setting up `shell-file-name' to `cmd'?  Are there reasons not
  to do so?

Best regards,
Fabrice

[1] FYI, I left explicit-shell-file-name as it was initially in my config:
(setq explicit-shell-file-name "bash").

[2] I loose, anyway, the ability to call personal (Bash) scripts on buffers or
regions from within Emacs, when switching to `cmdproxy'.