projectile
projectile copied to clipboard
bbatsov
`--strip-cwd-prefix` for `fd` doesn't work on versions <v8.3.0
Expected behavior
Running projectile-find-file with older (< v8.3.0) versions of fd installed prompts the user with a list of project files.
Actual behavior
Running projectile-find-file with older version of fd shows the user an error.
Steps to reproduce the problem
- Install a version of
fd<v8.3.0 (e.g. use Fedora 37 or older) - Run
projectile-find-filein Emacs withprojectileinstalled.
Environment & Version information
Projectile version information
Projectile 20220719.446
(Melpa)
Emacs version
GNU Emacs 27.2
Operating system
Fedora Silverblue 37; inside Fedora 36 toolbox.
Related
- Source
-
fdPR introducing--strip-cwd-prefix -
Issue requesting
--strip-cwd-prefix - Doom bug report
- Doom override PR
A workaround is to add the following line to your configuration:
(setq projectile-generic-command "fd . -0 --type f --color=never")
It looks like --strip-cwd-prefix is a little more complicated option than initially expected... Looking at fd repo I can see some discussion going on about it and how it's conflicting with some other options (and even does nothing in some cases).
Would it make more sense to, instead of using --strip-cwd-prefix, use something similar to what we do for find command (pipe it to cut -c3-)?
It looks like if we don't pass a path (last argument of fd) it will not add that leading cwd prefix which will break the output if we pipe it to cut -c3c BUT if we pass a path as . then it will add it as leading prefix hence cut would work.
fd . --type f --color=never . | cut -c3-
Should do the trick. It should work for all fd versions.
Looking at find command I don't really understand what that | tr '\\n' '\\0' does but if needed we can use it for fd output as well.
@acristoffers what do you think?
Using fd directly would be better for performance on large projects, as was a concern in the original issue. Maybe a version check could be performed to verify if the option is supported or not. I don't know how the project handles old versions of the tools it uses, though, so maybe leaving it to the user (maybe with better awareness), as stated by @J3RN, could also be an option. In the end, I think we need someone more involved with the project to have a say, as this was my first contribution, although I think that checking the version and providing both options would be the best. The problems with the flag don't affect us much, as we always use it the same way, and the problem comes from very weird decisions regarding piping or no piping.
Historically we've never tried to check capabilities of external tools, as that would add some complexity. Generally we just document such cases in the docs and the docstrings and we expect that the users will eventually read them.
I agree about checking the version. More conditions -> more complexity.
On the other hand it sounds to me as win-win if we can change the command to work with newer and older versions of fd. Just to clarify, I believe it's possible without checking the fd version.
I'll play with it on my end and if I can do this, I'll make a PR if you guys not mind.
Alright guys. Just a small update on this. The issue turned out to be not as simple as I wanted and expected. The closed PR attached is me thinking I solved it but I actually didn't.
fd initially didn't add cwd prefix. They have added it pretty recently. Then --strip-cwd-prefix was added as well.
So on fd versions < 8.3.0 there is no cwd prefix which breaks my idea of doing fd . --type f --color=never . | cut -c3-
There are two ways now:
- check the version and adjust the command accordingly
- update the docs to mention that required
fdis 8.3.0+ (maybe mention the workaround by @J3RN)
I suppose the second option is the one to go with
@krydos Agreed. Let's just update the docs and mention the configuration for older fd versions there.
A workaround is to add the following line to your configuration:
(setq projectile-generic-command "fd . -0 --type f --color=never")
Ever since https://github.com/bbatsov/projectile/commit/6dc58831a2c8bc6e036d9dc6549e2cda455dbf27 it appears that something like:
(setq projectile-git-fd-args "-H -0 -E .git -tf")
is also required to work around what looks like the same problem now that fd is being used in preference to git ls-files.
@mikecrowe You mean the current command for git repos doesn't work on older versions of fd or what?
@mikecrowe You mean the current command for git repos doesn't work on older versions of fd or what?
@bbatsov In short, yes.
The default value of projectile-git-fd-args is -H -0 -E .git -tf --strip-cwd-prefix. The version of fdfind in Debian 11 ("Bullseye", current stable) also does not support --strip-cwd-prefix.
When I updated to MELPA projectile 20230317.1101 earlier this week I started running into exactly the same error reported in this issue. The explanation in this issue made sense, but the suggested workaround didn't work for me. So I went digging in the code and found another recently-added use of --strip-cwd-prefix in projectile-git-fd-args. Removing that fixed the error and didn't seem to cause any ill effects. I commented in the hope of helping anyone else who also ran into this. (I never saw the problem back in August. Perhaps this is because I only ever use projectile-find-file in Git repositories.)
For this use case I guess it's also fine to just disable the functionality with projectile-git-use-fd set to nil.
On my system the fd-find executable installed using apt on Debian bullseye was too old, but fd from fd-find installed using cargo install is fine.
(setq projectile-fd-executable "fd")
fixed it for me.
