mu4e on windows with mu in WSL

[samvidmistry]

I'm back with another approach to make mu4e on windows work with mu in WSL. I was playing with mu4e with the intention to define an advice around mu4e--server-call-mu to translate whatever paths are being returned from mu. However, I discovered a really useful behavior of insert-file-contents on windows, making it unnecessary to transform any paths. My interaction on Emacs mailing list is here. I'm reproducing the email here as the email text will explain it better.

From: samvid mistry [email protected]
Date: Sat, 20 Jan 2024 12:00:46 +0530

I was playing with some code and found an unusual behaviour of
insert-file-contents. I am running GNU Emacs 29.1 on Windows. When I am
in a file/buffer that is within WSL, accessed using
//wsl.localhost/Ubuntu/..., I can open WSL paths without the prefix,
i.e., I can write (insert-file-contents "/home/samvid/davmail.log")
instead of (insert-file-contents "//wsl.localhost/Ubuntu/home/samvid/davmail.log") and it will open the
correct file. However, running (insert-file-contents "/home/samvid/davmail.log") when I am in a buffer/file on windows
filesystem, it will run into this error

(file-missing "Opening input file" "No such file or directory" "c:/home/samvid/davmail.log")

Isn't this just normal prepending of the drive letter to a file name
that lacks it? I'm guessing that when you are in a buffer whose name
begins with //wsl.localhost/Ubuntu/... Emacs prepends that to a file
name without a drive letter, whereas in a buffer on the C: drive, it
prepends C:/ instead.

Emacs on Windows doesn't consider file names that begin with a slash
as absolute file names, unless they have are in UNC format and begin
with two slashes.

Basically, if you start mu4e from any buffer within //wsl.localhost/Ubuntu/..., insert-file-contents will prepend the drive letter, in this case //wsl.localhost/Ubuntu/ to all paths, pointing it to the right file. The whole thing works transparently as far as mu4e is concerned.

Then why am I relaxing the validations?

mu is not a windows native program. It is available in WSL. Hence (file-executable-p mu4e-mu-binary) will always return false. Moreover, we need to start mu in WSL, which can be done by setting

(setq mu4e-mu-binary "wsl mu")

and running mu as a shell command instead of a windows native process. Is there a way to incorporate these changes in mu4e? We can then maybe explain in the README how one can get this setup working on Windows.

[djcb]

Ah, thanks, that's much less intrusive! Did you test on Linux as well?

[samvidmistry]

@djcb I have addressed your comment as well as added a section in README explaining how to make it work on Windows. I cannot test on Linux as I do not have a Linux machine. FWIW, I was able to test it on a Mac, which should be close enough. Let me know if any more changes are needed.

[samvidmistry]

I should note that I have tested the changes by modifying the existing installation. I could not compile mu from source to be able to test these changes. So it'll be good if you can spare some time to test these changes as well.