WSL Support

[goldfita]

What do you think about WSL support? I've been able to get ripgrep and treemacs, which uses python on windows, working without much difficulty. The trouble with git is that it's being used to return a file path, specifically getting the root of the project using magit-toplevel. Somehow this ends up getting tacked onto the current path. I don't understand exactly what's happening, but the general issue is clear.

/wsl/home/share/eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/lsp4j/extended/C:/Development/eclipse.jdt.ls/

I tried using git from within WSL, but it was unusably slow. I could probably work around this problem, but there may be other windows paths that need to be translated. Translating paths is easy to do using wslpath, but it would need to be wrapped around every path coming back from git.

[tarsius]

What do you think about WSL support?

I would like to support it, but since I don't use Windows I don't know to what extend we already do and what additional work would be involved. And maybe more importantly I have no way of trying it out.

One major problem with Windows is that one can combine various components in our case mostly emacs and git, that were compiled using different libraries (native-windows/cygwin/mingw/wsl1/wsl2), and that they have multiple (conflicting) options to make them work "better" with one another. This is especially the case when it comes to different ways of representing the same path.

It could be that what you want to do is already possible and that you are just "holding it wrong". Or maybe we have yet more path translation code to Magit. The problem with the latter is that there is a big risk that by supporting "paths as they appear with your setup" would break what is already working for other users and their respective setting.

I recommend you start by finding other wsl users first (maybe on the Emacs reddit) and ask them for guidance.

[goldfita]

Yeah, supporting multiple platforms and environments is a huge pain. I made a little wrapper that intercepts the query for the top level and translates the result with wslpath. This may be good enough.

[tarsius]

You might want to post that here, for the benefit of other users who use the same combination of software.

As a side-note, so far we have been using magit-expand-git-file-name and magit-convert-filename-for-git for path mangling. If possible, it would probably be best if you're wrapper were changes to these functions.

[goldfita]

It's an external script. I think treemacs also uses git. If I handle translation outside of emacs, then there's a chance it will work for other packages as well. It's quick fix, but it seems to work.

#!/bin/bash
git_exe=/win/software/git/bin/git.exe
if [[ "$*" =~ rev-parse ]] && [[ "$*" =~ --show-toplevel ]]; then
    /wsl/usr/bin/wslpath $("$git_exe" "$@")
else
    "$git_exe" "$@"
fi

[ncalexan]

I'm quite interested in making this work and have gotten to a similar place as @goldfita.

To clarify the "WSL support" title: if I use the Linux /usr/bin/git, then Magit works as expected. It's very slow, but Magit appears to work as expected.

Unfortunately there are many issues when using git.exe from a Windows Git installation around paths, and I doubt that it will be easy to work around them: there are many places in Magit that invoke file-name-absolute-p, expand-file-name, etc. It's not clear to me if the sensible approach is for Magit to use "WSL" paths ("/mnt/c/path/to/foo") or "Windows (git.exe) paths" ("c:/path/to/foo"). It seems to me very unlikely that Windows paths will be possible: Magit simply does too many file operations (loading into buffers, etc). But then Magit would need to convert its WSL paths into Windows paths for git.exe to consume. Perhaps that doesn't happen as much as I fear it does?

[ncalexan]

Maybe I was too hasty. With the following hacky patch:

diff --git a/lisp/magit-git.el b/lisp/magit-git.el
index fdd0e894..2d679bc3 100644
--- a/lisp/magit-git.el
+++ b/lisp/magit-git.el
@@ -1211,8 +1211,22 @@ Sorted from longest to shortest CYGWIN name."
   :group 'magit-process
   :type '(alist :key-type string :value-type directory))
 
+(defun magit-file-name-absolute-p (filename)
+  "Whether FILENAME is absolute.
+1. If it is an absolute filename per `expand-file-name'.
+2. If it starts with a Cygwin mount point XXX."
+  (cond
+   ((file-name-absolute-p filename) t)
+   ((cl-assoc filename magit-cygwin-mount-points
+               :test (lambda (f cyg) (string-prefix-p cyg f))) t)))
+
 (defun magit-expand-git-file-name (filename)
-  (unless (file-name-absolute-p filename)
+  (unless (magit-file-name-absolute-p filename)
     (setq filename (expand-file-name filename)))
   (if-let ((cyg:win (and (not (file-remote-p default-directory)) ; see #4976
                          (cl-assoc filename magit-cygwin-mount-points
@@ -1228,7 +1242,7 @@ Sorted from longest to shortest CYGWIN name."
    Git does not understand.
 2. If it is a remote filename, then remove the remote part.
 3. Deal with an `windows-nt' Emacs vs. Cygwin Git incompatibility."
-  (if (file-name-absolute-p filename)
+  (if (magit-file-name-absolute-p filename)
       (if-let ((cyg:win (cl-rassoc filename magit-cygwin-mount-points
                                    :test (lambda (f win) (string-prefix-p win f)))))
           (concat (car cyg:win)
@@ -1328,7 +1342,9 @@ If there is no output, return nil."
   "Execute `git rev-parse ARGS', returning first line of output.
 If there is no output, return nil.  Like `magit-rev-parse' but
 ignore `magit-git-debug'."
-  (apply #'magit-git-str "rev-parse" args))
+  (let ((value (apply #'magit-git-str "rev-parse" args)))
+    (if (-contains? '("--show-toplevel") (-first-item args))
+        (magit-expand-git-file-name value))))
 
 (defun magit-rev-parse-true (&rest args)
   "Execute `git rev-parse ARGS', returning t if it prints \"true\".

and

  (setq magit-git-executable "git.exe")
  (setq magit-cygwin-mount-points '(("c:/" . "/mnt/c/") ("C:/" . "/mnt/c/")))

This seems to be working for me. I'll keep working with this and see what, if anything breaks. Maybe we can support WSL without significant path translations?

[goldfita]

You may find wsl-path.el helpful. I ran into some problems with infinite recursion. When I replaced the emacs path translation with the wslpath utility, I was able to get it working.

Even with wsl-path.el, I had to override a few functions to get lsp-mode working. It wasn't that bad. The issue is that you have to get into the guts of every package that runs external applications from windows, unless the author made the decision to support WSL.

[phil-s]

https://emacs.stackexchange.com/questions/82970/m-x-magit-status-extremely-slow-on-large-repository turned out to be related to WSL. Adding the link as a data point.