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 commented 4 months ago

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 commented 4 months ago

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

ManuelAF commented 4 months ago

I think the new behavior was introduced here #236

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

cprusprus commented 4 months ago

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 commented 3 months ago

Use fdfind to get the relative path of file.

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

ManuelAF commented 3 months ago

I'm already using it

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

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[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'