bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

[Siyuan Chen]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

Reproduces steps:

I have the following directory

```

\---myproject
    |  .project
    |
    +---subproject1
    |   \---.git
    |   |   Makefile
    |
    \---subproject2
        \---.git
        |   Makefile

```

1. Open Emacs -Q

2. M-x eval-expression `(setq debug-on-error t)`

3. M-x eval-expression `(setq project-vc-extra-root-markers '(".project"))`

4. Open the .project file in Emacs

5. M-x eval-expression `(project-current)`

    Result: `(vc nil "e:/work/myproject/")` OK

6. M-x eval-expression `(project-files (project-current))`

    Result: Debugger entered--Lisp error: (error "File listing failed:
FIND: Parameter format not co...")
  error("File listing failed: %s" "FIND: Parameter format not correct\n")

The root cause is that `project--files-in-directory` in project.el is using
`find-program` ("find") which does not exist on Windows.

Is it possible to use more portable code? For example,
`directory-files-recursively`? Otherwise NTEmacs users will have to install
CYGWIN or MSYS2.

P.s. I have used Projectile before, which allows you to place a .projectile
file in `myproject` and everything was OK on Windows. Also if I focus on a
git folder e.g. `subproject1` in the example above, the `project-files`
also works well.

Emacs 29.3 on Windows 10.

Thanks.

Best Regards,
Siyuan Chen

[-- Attachment #2: Type: text/html, Size: 2199 bytes --]

bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

[Siyuan Chen]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

Anyway, setting `(setq find-program (purecopy
"C:/msys64/usr/bin/find.exe"))` makes the above example work at the moment.

Perhaps all NTEmacs users should set the 3 options: grep-program,
find-program, xargs-program. My only concern now is the potential issue
with backslashes and encoding. Hence, I have to keep Projectile as the
fallback solution because it has a native implementation.

Best Regards,
Siyuan Chen


On Tue, Jun 25, 2024 at 5:37 AM Siyuan Chen <chansey97@gmail.com> wrote:

> Reproduces steps:
>
> I have the following directory
>
> ```
>
> \---myproject
>     |  .project
>     |
>     +---subproject1
>     |   \---.git
>     |   |   Makefile
>     |
>     \---subproject2
>         \---.git
>         |   Makefile
>
> ```
>
> 1. Open Emacs -Q
>
> 2. M-x eval-expression `(setq debug-on-error t)`
>
> 3. M-x eval-expression `(setq project-vc-extra-root-markers
> '(".project"))`
>
> 4. Open the .project file in Emacs
>
> 5. M-x eval-expression `(project-current)`
>
>     Result: `(vc nil "e:/work/myproject/")` OK
>
> 6. M-x eval-expression `(project-files (project-current))`
>
>     Result: Debugger entered--Lisp error: (error "File listing failed:
> FIND: Parameter format not co...")
>   error("File listing failed: %s" "FIND: Parameter format not correct\n")
>
> The root cause is that `project--files-in-directory` in project.el is
> using `find-program` ("find") which does not exist on Windows.
>
> Is it possible to use more portable code? For example,
> `directory-files-recursively`? Otherwise NTEmacs users will have to
> install CYGWIN or MSYS2.
>
> P.s. I have used Projectile before, which allows you to place a
> .projectile file in `myproject` and everything was OK on Windows. Also if I
> focus on a git folder e.g. `subproject1` in the example above, the
> `project-files` also works well.
>
> Emacs 29.3 on Windows 10.
>
> Thanks.
>
> Best Regards,
> Siyuan Chen
>
>

[-- Attachment #2: Type: text/html, Size: 2925 bytes --]

bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

[Eli Zaretskii]

tags 71762 notabug
thanks

> From: Siyuan Chen <chansey97@gmail.com>
> Date: Tue, 25 Jun 2024 08:04:48 +0800
> 
> Anyway, setting `(setq find-program (purecopy "C:/msys64/usr/bin/find.exe"))` makes the above example work
> at the moment. 

That's one possible solution.  Another is to rearrange your system's
PATH so that the directory C:\msys64\usr\bin comes _before_ the
C:\WINDOWS\system32, where you have the stock Windows find.exe (which
is a program for a completely different purpose and with completely
different command-line syntax).

Byw, the "msys64" part of the directory where you have find.exe seems
to hint that it is an MSYS port, not a native Windows/MinGW port.  If
that is indeed so, my recommendation is to install a native find.exe
and use that instead, as MSYS ports could have subtle
incompatibilities with a native Windows Emacs.

> Perhaps all NTEmacs users should set the 3 options: grep-program, find-program, xargs-program.

These variables already exist, so I'm not sure what you are suggesting
here.

In general, the only "problematic" program is find.exe, because
Windows comes only with that.  The other two programs must be
installed, and so there's no danger of Emacs invoking the wrong one.

I see no Emacs bug here, just an issue of configuring your system
and/or Emacs correctly.

> My only
> concern now is the potential issue with backslashes and encoding.

There should be no such issues, if you find one, please report that as
a bug.

bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

[Dmitry Gutov]

On 25/06/2024 00:35, Siyuan Chen wrote:
> 
> Is it possible to use more portable code? For example, 
> `directory-files-recursively`? Otherwise NTEmacs users will have to 
> install CYGWIN or MSYS2.

There are also GNU tools available for download separately, e.g. see the 
ezwinports project.

I'm wary of using directory-files-recursively - because the performance 
can be much different. While right now you see the error and are thus 
encouraged to fix it by installing an extra program or two, in the other 
case the user would just see poor performance (given a large enough 
project) and perhaps some reduced features wrt filtering. And might not 
realize that it's not how the feature is supposed to work.

Also note that 'find.exe' is only required when you have a project 
that's outside of any Git repositories.

> P.s. I have used Projectile before, which allows you to place a 
> .projectile file in `myproject` and everything was OK on Windows. Also 
> if I focus on a git folder e.g. `subproject1` in the example above, the 
> `project-files` also works well.

Projectile has some different tradeoffs, e.g. you might have to reset 
the file cache manually in the above setup. It also has several indexing 
methods to choose from, each with pros and cons.

bug#71762: `(project-files (project-current))` with `project-vc-extra-root-markers` doesn't work on Windows.

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 71762 notabug
> thanks
>
>> From: Siyuan Chen <chansey97@gmail.com>
>> Date: Tue, 25 Jun 2024 08:04:48 +0800
>>
>> Anyway, setting `(setq find-program (purecopy "C:/msys64/usr/bin/find.exe"))` makes the above example work
>> at the moment.
>
> That's one possible solution.  Another is to rearrange your system's
> PATH so that the directory C:\msys64\usr\bin comes _before_ the
> C:\WINDOWS\system32, where you have the stock Windows find.exe (which
> is a program for a completely different purpose and with completely
> different command-line syntax).
>
> Byw, the "msys64" part of the directory where you have find.exe seems
> to hint that it is an MSYS port, not a native Windows/MinGW port.  If
> that is indeed so, my recommendation is to install a native find.exe
> and use that instead, as MSYS ports could have subtle
> incompatibilities with a native Windows Emacs.
>
>> Perhaps all NTEmacs users should set the 3 options: grep-program, find-program, xargs-program.
>
> These variables already exist, so I'm not sure what you are suggesting
> here.
>
> In general, the only "problematic" program is find.exe, because
> Windows comes only with that.  The other two programs must be
> installed, and so there's no danger of Emacs invoking the wrong one.
>
> I see no Emacs bug here, just an issue of configuring your system
> and/or Emacs correctly.

I'm therefore closing this bug report.