New CTRL-T behaviour

[ManuelAF]

Till version 2.5.22 using ctrl-t the relative path of the selection was sent to the command line, now with the version 2.5.22 the full path (c:\users...) is sent, is there any way to change it ?

[cprusprus]

I can only reproduce this when Set-PsFzfOption -EnableFd is enabled. I'll do like c:\temp ctrl-t and with that option enabled I end up with c;\tempc:\temp\test.txt. Without the option enabled I get c:\temp\test.txt as expected.

I believe it likely has to do with an alias conflict for this script and the winget sharkdp.fd package, which puts fd.exe in the path, used by neovim telescope plugin.

[ManuelAF]

The only change is upgrading from 2.5.19 to 2.5.22, till this update I do someting like notepad ctrl-t (and select a file) an the path added to the command line is relative, now with the 2.5.22 update, is a full path, but if you do notepad .ctrl-t(and select a file) even with the 2.5.22 version you get a relative path

[cprusprus]

I see what you mean yeah, I get full paths too if I precede with an application like notepad.

[ManuelAF]

I think the new behavior was introduced here #236

https://github.com/kelleyma49/PSFzf/blame/a02741b05390fc69e472048d7008ca145cf4dcc7/PSFzf.Base.ps1#L748

[cprusprus]

Why was it even touching the pre-existing path fragment the user had on the command line before invoking PSFzf? That seems like the wrong algorithm. That portion of the CL should be read-only, Ideally, PSFzf takes it in as a parameter and adjusts results based on it.

IOW that change didn't fix the underlying issue with #236, it simply changed to use full paths as output.

Is there a reason this regression breaks existing workflows (relative vs absolute paths)?

[owenstake]

Use fdfind to get the relative path of file.

$env:FZF_CTRL_T_COMMAND="fd --color always"

[ManuelAF]

I'm already using it

$env:FZF_CTRL_T_COMMAND='fd --hidden --follow --exclude .git --exclude node_modules --exclude .vs --exclude .vscode'