Non ASCII chars are not shown fzf

[mrkingmidas]

Hello!

Non ASCII chars are not shown fzf:
There is a description of the solution in Can't input non ascii characters #3799 - specify --no-height and it works, but only for an independent call in cmd.

If I set fzf.height = in clink_settings and SET FZF_DEFAULT_OPTS=--no-height, then pressing Ctrl+T does not work. In the task manager com. the line "fzf.exe" --reverse --scheme=path --no-height -i -m - if called directly, it works correctly.

My knowledge of lua is extremely low, apparently the problem is somewhere in the code

local r = io.popen(command..' 2>nul | '..get_fzf('path')..' -i -m')

I use ConEmu on Windows 10.

Add:
In command=dir /b /s /a:d-s $dir that returns in codepage=866

[mrkingmidas]

I am find ugly solution with iconv.exe:

In my startup bat script set:

SET FZF_DEFAULT_OPTS=--no-height
SET FZF_CTRL_T_COMMAND=dir_utf8 /b /s /a:-s $dir
SET FZF_ALT_C_COMMAND=dir_utf8 /b /s /a:d-s $dir

and in PATH place dir_utf8.bat with:

@DIR %* | iconv -c -f 866 -t utf-8           

[chrisant996]

I don't think this is related to clink-fzf.

But Clink uses utf8.

And since fzf is a *nix app cross-compiled for Windows, fzf probably uses utf8.

Read the section icons in fzf which mentions the dirx program and its --utf8 flag.

[mrkingmidas]

I don't think this is related to clink-fzf.

But Clink uses utf8.

And since fzf is a *nix app cross-compiled for Windows, fzf probably uses utf8.

Read the section icons in fzf which mentions the dirx program and its --utf8 flag.

Thank you!

Now with dirx --utf8 work:

SET FZF_DEFAULT_OPTS=--no-height
SET FZF_CTRL_T_COMMAND=dirx --utf8 /b /s /a:-s $dir
SET FZF_ALT_C_COMMAND=dirx --utf8 /b /s /a:d-s $dir

[chrisant996]

I'll add some text in the README about fzf's utf8 expectation. Maybe I can even find a way to allow configuring whether clink-fzf's fzf.lua script should convert from system code page to utf8, to compensate.

But really the fzf program itself would benefit from a flag to control code page conversion. If no such flag exists in the fzf program, then what would be a gap in the Windows cross-compiled version of fzf itself.

[chrisant996]

Maybe I can even find a way to allow configuring whether clink-fzf's fzf.lua script should convert from system code page to utf8, to compensate.

There isn't a good way for the fzf.lua script to convert the input, because it isn't even involved.

An important feature of fzf is that it lets you search even before all the content has been loaded. For example, you can immediately start searching even while a long-running dir /s /b c:\ command is running. For that feature to work, there needs to be an external program feeding content to fzf, such as the dir command. The fzf.lua script can't just scan the drive, give the file names to fzf, and then let the user type -- because that would be very slow and would defeat the asynchronous searching capabilities of fzf.

But really the fzf program itself would benefit from a flag to control code page conversion. If no such flag exists in the fzf program, then what would be a gap in the Windows cross-compiled version of fzf itself.

I opened junegunn/fzf#4065 for that, and I also commented on junegunn/fzf#3799. Both are Windows-specific issues; 4065 is about processing redirected stdin, and 3799 is about processing direct keyboard input.

I'll add some text in the README about fzf's utf8 expectation.

Done (here).

[chrisant996]

Closing this issue. The clink-fzf documentation now covers the FZF known issues about Unicode content. The rest of what's discussed here lies in FZF itself and is tracked by the FZF issues cited above.

[chrisant996]

I've made changes in fzf.lua to automatically add a chcp 65001 workaround, and to restore the original codepage afterwards.

That should eliminate the need for adding custom user-configured workarounds.

(See commit 76a76a1.)