projectile-find-file and +default/search-cwd (fd) incorrectly expand '/' to absolute path on Windows

[Ruin0x11]

What did you expect to happen?

projectile-find-file and +default/search-cwd should list nested paths correctly.

What actually happened?

In Windows with mingw installed, this kind of output is displayed for both commands:

Additional details:

See this issue for details:

BurntSushi/ripgrep#501 (comment)

I fixed this issue with the following snippet:

(after! ivy
  (when IS-WINDOWS
    (setq counsel-rg-base-command "rg -M 240 --with-filename --no-heading --line-number --color never %s --path-separator // .")))

(after! projectile
  (when (executable-find doom-projectile-fd-binary)
    (setq projectile-generic-command
          (concat (format "%s . -0 -H -E .git --color=never --type file --type symlink --follow"
                          doom-projectile-fd-binary)
                  (if IS-WINDOWS " --path-separator=//")))))

System information:

emacs   version    26.2
        features   XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2
        build      4 13, 2019
        buildopts  (--without-dbus --host=x86_64-w64-mingw32 --without-compress-install 'CFLAGS=-O2 -static -g3')
        windowsys  w32
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD a262527a7 2020-05-21 04:33:39 -0400
        dir        ~/.doom.d/
system  type       windows-nt
        config     x86_64-w64-mingw32
        shell      C:\Program Files\Git\usr\bin\bash.exe
        uname      n/a
        path       (C:\Users\kuzuki\bin C:\Program Files\Git\mingw64\bin C:\Program Files\Git\usr\local\bin C:\Program Files\Git\usr\bin C:\Program Files\Git\usr\bin C:\Program Files\Git\mingw64\bin C:\Program Files\Git\usr\bin C:\Users\kuzuki\bin C:\Program Files\ImageMagick-7.0.10-Q16 C:\Python27 C:\Python27\Scripts C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\libnvvp C:\bin\ImageMagick C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\bin C:\Program Files\PuTTY C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files (x86)\LuaRocks C:\Program Files\LOVE C:\bin\Ruby26-x64\bin C:\bin\emacs-26.2\bin C:\Program Files\NVIDIA Corporation\Nsight Compute 2019.4.0 C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\WINDOWS\System32\OpenSSH C:\Program Files (x86)\arbtt\bin C:\Program Files\TortoiseHg C:\bin\nodejs C:\ProgramData\chocolatey\bin C:\Program Files\dotnet C:\Program Files\Microsoft SQL Server\130\Tools\Binn C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn C:\Program Files\CMake\bin C:\Program Files\Microsoft SQL Server\120\Tools\Binn C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn C:\Program Files\Microsoft SQL Server\100\Tools\Binn C:\Program Files\Microsoft SQL Server\100\DTS\Binn C:\Program Files (x86)\Common Files\GTK\2.0\bin C:\Program Files\Zulu\zulu-13-jre\bin C:\bin\graphviz\bin C:\bin\luajit\bin C:\Program Files\Git\cmd C:\Users\kuzuki\.cargo\bin C:\Program Files (x86)\Nmap C:\Users\kuzuki\AppData\Local\Microsoft\WindowsApps C:\bin\Ruby26-x64\bin C:\Program Files (x86)\FlacSquisher C:\bin\vgmstream C:\bin\hsp351 C:\Users\kuzuki\AppData\Local\Programs\Microsoft VS Code\bin C:\Users\kuzuki\AppData\Roaming\npm C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.3\bin C:\Users\kuzuki\MacOS9\GTK\2.0\bin C:\bin\graphviz\bin C:\bin\luajit\src C:\Program Files\smartmontools\bin C:\Users\kuzuki\build\doom-emacs\bin C:\Program Files\Git\usr\bin\vendor_perl C:\Program Files\Git\usr\bin\core_perl c:/bin/emacs-26.2/libexec/emacs/26.2/x86_64-w64-mingw32/)
config  envfile    envvar-file
        elc-files  0
        modules    (:input japanese :completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline ophints (popup +defaults) vc-gutter vi-tilde-fringe workspaces :editor (evil +everywhere) file-templates fold snippets :emacs dired electric undo vc :checkers syntax :tools (eval +overlay) lookup lsp magit :lang emacs-lisp lua markdown org sh :config (default +bindings +smartparens))
        packages   ((lispyville))
        unpin      (n/a)
        elpa       (n/a)

[hlissner]

Is this a universal solution (for all Windows users)? Do we need to detect mingw running bash vs mingw not running bash?

[hlissner]

And if this is a universal solution, should it (at least the counsel-rg-base-command fix) be reported to counsel?

[Ruin0x11]

It has been reported to counsel, but it's blocked on a large-scale refactoring.

abo-abo/swiper#2351

[ghost]

@Ruin0x11, thank you for the snippet you've provided, I'm new to doom-emacs and it is essential for me to use it across different systems including Windows.

GNU Emacs 26.1
Windows10 1809

[chuxubank]

You should add MSYS2_ARG_CONV_EXCL=--path-separator= in to your environment.
See sharkdp/fd#537 (comment)

[guraltsev]

Ack, I linked the wrong issue. Ah well, this should be fixed in f548ab6. I'll leave this open until it is addressed upstream.

This commit breaks things for me.

Before that +default/search-project worked without any problem. Now the same command gives an empty result with

error code 2

I bisected the commits and that is the one responsible

[guraltsev]

Actually, further investigation shows that the new rg command is invalid under windows:

C:\Users\guraltsev\.config>rg --path-separator // test
A path separator must be exactly one byte, but the given separator is 2 bytes: //
In some shells on Windows '/' is automatically expanded. Use '//' instead.

while

C:\Users\guraltsev\.config>rg --path-separator / test

works perfectly.

I have the latest rg for windows:

C:\Users\guraltsev\.config>rg --version
ripgrep 12.1.1 (rev 7cb211378a)
-SIMD -AVX (compiled)

[guraltsev]

@hlissner

Is this a universal solution (for all Windows users)? Do we need to detect mingw running bash vs mingw not running bash?

Apparently not. Running

rg --path-separator / test

works in CMD but not in a mingw shell
while works in mingw

rg --path-separator // test

but not in a standard cmd prompt.

[Whil-]

Just want to comment that in a similar fashion I had to change the --path-separator // that gets set for counsel-rg-base-command somewhere to use a single /.

(if (eq system-type 'windows-nt)
    (setq counsel-rg-base-command
          "rg -M 240 --with-filename --no-heading --line-number --color never %s --path-separator / ."))

Also using Windows 10 and probably (?) standard cmd shell.

[hlissner]

Not a Windows user, so I can't do extensive testing on this. Can anyone recommend a workaround (perhaps to detect whenever // is necessary)? Or am I forced to always throw one group of users under the bus? If so, any insight into which use case is more common for Emacs users on Windows?

[davorao]

Can't speak in general, but on my work PC the suggestion from @guraltsev works wonders.
I just added the snippet from #3215 (comment) to my .doom.d/config.el and can use ripgrep as is from dooms default configuration.

PC config:
ripgrep and emacs installed via scoop
only the snippet from @guraltsev in my config.el

[hlissner]

Can't speak in general, but on my work PC the suggestion from @guraltsev works wonders.

That's not quite what I was asking for. I meant a fix to determine whether --path-separator / or --path-separator // is necessary at call time. Guraltsev's solution is to replace one with the other, once and globally, but that doesn't solve the issue for users for whom that setting is necessary for it to work.

[chuxubank]

Agree, the more general solution is to use the MSYS2_ARG_CONV_EXCL=--path-separator= environment as I said above.

[hlissner]

@chuxubank Ah, I missed that. That's perfect. I'll look into incorporating that into Doom soon. Thanks!

[hlissner]

As of 523e945 this issue should be resolved. Let me know if that isn't the case and I'll reopen it.

[hliebert]

I am still experiencing this bug on Windows 10. Setting the path separator to a single slash resolves it. rg installed via scoop.

[hlissner]

@hliebert Are you sure you've updated Doom? It is already set to a single slash.

[hliebert]

This was on a new install, I got a new windows laptop from work. I had installed it the day before I posted.

[hliebert]

@hlissner Just tested and can confirm this still occurs on the latest doom.

Doom v2.0.9 (ffbd7b63bf7290b6cd6fc3f1b41110876864fe83)
Emacs v26.3
Branch: develop
Build date: 2020-08-02 01:33:51 -0400

Edit: Apparently the default value is changed somewhere.

counsel-rg-base-command is a variable defined in counsel.el.

Value
("rg" "-M" "240" "--with-filename" "--no-heading" "--line-number" "--color" "never" "%s" "--path-separator" "//" ".")

Original Value
("rg" "-M" "240" "--with-filename" "--no-heading" "--line-number" "--color" "never" "%s" "--path-separator" "/" ".")

[Sloff]

Same story for me as @hliebert, latest Doom, Emacs and rg installed via scoop, and the original value for counsel-rg-base-command is being changed somewhere to use 2 slashes

[hlissner]

Try 8024f4e. Should hopefully fix this.

[Sloff]

Working perfectly, thanks @hlissner!