clojure-jack-in might have problems under Win

[ath]

On a Windows Server 2003 I set the environment variable %HOME% to C:\Documents and Settings\at I downloaded a fresh Emacs Starter Kit and unpacked it into C:\Documents and Settings\at.emacs.d and added a init.el, as described in the readme. Then I installed clojure-mode and in the shell I did a lein plugin install swank-clojure 1.3.3

Now I open my project.clj in Emacs and do a M-x clojure-jack-in but get the following error messages: Starting swank server... error in process filter: byte-compile-file: Opening input file: no such file or directory, c:/Documents and Settings^Gt/.emacs.d/swank/slime-cdf283b4.el error in process filter: Opening input file: no such file or directory, c:/Documents and Settings^Gt/.emacs.d/swank/slime-cdf283b4.el

It seems to me that there might be a bug when constructing the path to the home dir, so that a Control+G gets inserted. One idea was, but that could be totally wrong, that it has to do with the \a in my home path that translates into an alarm or something like that. The t after the ^G looks good to me. The file that is needs to be read exists, under the nearly correct path: c:/Documents and Settings/at/.emacs.d/swank/slime-cdf283b4.el

Any ideas?

[ath]

Maybe this issue should be copied to the clojure-mode issues and be closed here.

[ath]

Anyway, another addition: when doing the jack-in I look into the swank buffer, and there I see: (when (not (featurep 'slime-cdf283b4)) (if (file-readable-p "C:\Documents and Settings\at/.emacs.d/swank/slime-cdf283b4.elc") (load-file "C:\Documents and Settings\at/.emacs.d/swank/slime-cdf283b4.elc") (byte-compile-file "C:\Documents and Settings\at/.emacs.d/swank/slime-cdf283b4.el" t))) (when (not (featurep 'slime-repl-79b38c83)) (if (file-readable-p "C:\Documents and Settings\at/.emacs.d/swank/slime-repl-79b38c83.elc") (load-file "C:\Documents and Settings\at/.emacs.d/swank/slime-repl-79b38c83.elc") (byte-compile-file "C:\Documents and Settings\at/.emacs.d/swank/slime-repl-79b38c83.el" t))) (sleep-for 0.1) (run-hooks 'slime-load-hook) ; on port 65007 ;;; proceed to jack in

When I place my cursor on the closing paren of (file-readable-p "C:\Documents and Settings\at/.emacs.d/swank/slime-cdf283b4.elc") then I see exactly that wrong path showing up in the minibuffer.

[ath]

After skimming through the code I now have more the impression that this is an Emacs issue. Probably the windows testers didn't see that effect yet, in 24α.

[ath]

My current fix is: In C:\Program Files (x86)\emacs\lisp\emacs-lisp\bytecomp.el I applied a patch: after the (interactive ...) block I added (setq filename (replace-regexp-in-string "^G" "/a" filename))

I am not sure who calls byte-compile-file. It is triggered by clojure-jack-in from clojure-mode, but who is picking up the path? That fn may still have the chance to make a replacement from "\\" into "/" and work generally.

[kschuetz]

I have also had problems getting it to run in Windows.

The loader function in jack_in.clj appears to be responsible for constructing the command for emacs to do the byte-compiling. However, it doesn't appear to escape the backslashes before doing so and this confuses emacs.

In order for me to get up and running, I cheated and hard-coded the .emacs.d path for my machine right into the function:

elisp checksum (subs (hex-digest resource) 0 8) basename (format "e:/home/.emacs.d/swank/%s-%s" ;; <- hard-coded here ;; (System/getProperty "user.home") feature checksum) elisp (str basename ".el")

and then dropped it back into the jar.

[ath]

Okay, if that works for you then this seems to be indeed the place where the paths are constructed. I suggest that Leiningen replace the path construction via format by resolution via the java.io.File constructor.

[ghost]

I had the same problem tonight and luckily found kschuetz's fix.

There seems to be a fix for this in a fork, here, https://github.com/frericksm/swank-clojure/commit/d592c4edfb70c86d88f8719f7e3dff32da1141b5, but I haven't been able to test it.

[radaczynski]

the only patch you need is to replace: (System/getProperty "user.home")

with (string/replace (System/getProperty "user.home") "\" "\")

is it not?

[paulrd]

rada: your suggestion did not work for me, but a variation of kschuetz suggestion does. Can anyone here implement a fix? Should I try to do this myself? My fix breaks every time I upgrade leiningen.

[nealgroothuis-zz]

I'm running into a very similar issue with Emacs under Cygwin. It appears that ELisp functions like byte-compile-file can't recognize absolute windows-style paths (e.g., c:\cygwin\home\ngroothuis), instead treating them as relative appending them to the current path. As a hack, I cygwin-ize the basename and use that in the loader() function in jack_in.clj, a la:

  (let [feature (second (re-find #".*/(.*?).el$" resource))
        checksum (subs (hex-digest resource) 0 8)
        filename (format "%s-%s" feature checksum)
        basename (-> (or (System/getenv "HOME")
                         (System/getProperty "user.home"))
                     (io/file ".emacs.d" "swank" filename)
                     (.getAbsolutePath)
                     (.replaceAll "\\\\" "/"))
        basename-cygwin (.replaceAll (re-matcher #"^(\w):" basename)
                                     "/cygdrive/$1")
        elisp (str basename-cygwin ".el")
        bytecode (str basename-cygwin ".elc")
        elisp-file (io/file elisp)]