Bare relative option adds extra fluff to paths
Closed this issue · 6 comments
Originally opened in the dirx repo, but was a clink-fzf issue.
If the --bare-relative option is supplied then extra fluff is shown for all the paths, mainly .\ (and/or .\\ if you nest dirx command for preview window).
These are the ALT + C suggestions for clink-fzf repository.
As you can see all the folders start with .\.
And if you also have the preview window enabled (set FZF_ALT_C_OPTS=--preview-window "right:40%,border-left" --bind "ctrl-/:change-preview-window(right:70%|hidden|)" --preview "dirx -b -s --bare-relative --utf8 --level=3 --icons=always {2..}") then the preview paths start with .\\
I'm not sure if this was happening in 0.9 or it only started happening with 0.10.
EDIT:
I just checked, it only started happening with 0.10.
Can you please share the dirx command line that was used?
If the command line is dirx --bare-relative . then it's intentional that it's supposed to list a .\ prefix before each path. The behavior in v0.9 was a temporary quick hack to get sort of close to the intended behavior quickly.
My testing of ls and eza on Ubuntu with bash and fzf seemed to indicate that's how other tools do it by default. Since dirx is aiming to match CMD DIR by default, a separate flag --bare-relative is needed to gain that behavior.
I may have missed something, though, so can you share the full command line you're using when running dirx?
--bare-relative When listing subdirectories recursively, print paths
relative to the specified patterns instead of expanding
them to fully qualified paths (implies --bare).
I figured out what you meant.
> blah Ctrl-T ended up listing .\ prefix when the FZF_..._COMMAND environment variables are configured to use dirx and include the --bare-relative flag.
That wasn't a dirx issue, it was a clink-fzf issue.
Moving this issue to the corresponding repo.
Fixed in fzf.lua to mimic how fzf works with fish on *nix.
(Which is only possible when using dirx instead of dir, and when adding the --bare-relative flag. The CMD dir command has no way to trim the paths and always prints fully qualified paths, but dirx has a way to mimic the path reporting behavior seen on fzf in *nix.)
I compared it with the way my Linux machine lists folders, where the ./ is not shown/present.
This is how ALT + C lists folders on my Linux Mint machine.
The fix was published earlier today.
Was an issue in fzf.lua, not DirX.
Thanks, already using it.
Noticed another possible issue with it, will be adding an issue shortly. I'm not sure if it's a clink-fzf issue though, might be a fzf issue.