Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preview.sh not previewing files with nested path on Windows #1513

Closed
7 of 12 tasks
zuqini opened this issue Nov 15, 2023 · 8 comments
Closed
7 of 12 tasks

preview.sh not previewing files with nested path on Windows #1513

zuqini opened this issue Nov 15, 2023 · 8 comments
Labels

Comments

@zuqini
Copy link

zuqini commented Nov 15, 2023

Info

  • OS
    • Linux
    • Mac OS X
    • Windows
    • Etc.
  • Shell
    • bash
    • zsh
    • fish

Problem / Steps to reproduce

Preview window is not showing file content for nested paths that include backslashes (e.g. after\ftplugin\lua.vim as opposed to lua.vim.
image
vs.
image

It looks like it's caused by bash not interpreting the unescaped \ from the path returned by fzf.vim\bin\preview.sh.

Reproduce directly with fzf by:

  1. running fzf --preview='bash {...}\.vim\plugged\fzf.vim\bin\preview.sh {}' --bind shift-up:preview-page-up,shift-down:preview-page-down
  2. select a file with a nested path

To further debug the problem, I logged the command returned by preview.sh and ran it in bash directly and saw that the backslash was swallowed:

> bash
 $ highlight -O ansi -l after\ftplugin\lua.vim || coderay after\ftplugin\lua.vim || rougify after\ftplugin\lua.vim || cat after\ftplugin\lua.vim
bash: highlight: command not found
bash: coderay: command not found
bash: rougify: command not found
cat: afterftpluginlua.vim: No such file or directory

If I escape the path, then it previews the file content successfully:

> bash
$ cat after//ftplugin//lua.vim
set expandtab
set shiftwidth=2
set softtabstop=2
set tabstop=2

Environment

This is happening on a new Windows 11 installation:

OS Name	Microsoft Windows 11 Pro
Version	10.0.22621 Build 22621

The vim version shouldn't matter since I reproduced the issue directly with preview.sh, but here it is anyway in case it helps:

NVIM v0.9.4
Build type: RelWithDebInfo
LuaJIT 2.1.1696883897

The bash.exe points to the git bash installed from scoop: C:\Users\{username}\scoop\apps\git\current\bin\bash.exe

I should note that this did not happen prior to my Windows 11 re-install. I have no idea what changed that suddenly caused this issue. Appreciate any pointers!

@junegunn
Copy link
Owner

Do you experience the same problem with the following command?

:call fzf#run(fzf#wrap({'options': ['--preview', 'cat {}']}))

@zuqini
Copy link
Author

zuqini commented Nov 18, 2023

Nope, that works!

@DMinsky
Copy link

DMinsky commented Apr 3, 2024

Same here. I could confirm that following works with vim in bash terminal.
:call fzf#run(fzf#wrap({'options': ['--preview', 'cat {}']}))

But in gvim cat is unavailable, so still no preview there.

@junegunn
Copy link
Owner

junegunn commented Apr 4, 2024

I don't have a Windows PC to debug and test this on. Pull requests are welcome.

@DMinsky
Copy link

DMinsky commented Apr 4, 2024

It seems I've found a workaround. Although it's not even a workaround, but rather an improvement of the default preview situation, and it's mentioned right in the README of fzf.vim 🫠.

You need to install bat. A tool that, as far as I understand, replaces cat and adds syntax highlighting in the preview window. I just unpacked the archive with the bat binary and added this path to my path. After that, the preview window began to display the contents of the selected files.

Screenshot 2024-04-04 140544

@mbilyanov
Copy link

How did you get the syntax highlighting to work in the preview window?

@DMinsky
Copy link

DMinsky commented Apr 12, 2024

How did you get the syntax highlighting to work in the preview window?

I literally did nothing except install bat. Just make sure the folder with the bat executable is available in the PATH so that fzf.vim can find it.

@junegunn
Copy link
Owner

Fixed in d91dd75.

And yeah, having bat would avoid the bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants