Cyrillic type input is not working on Windows when height parameter is used

[FallenGameR]

• [x] I have read through the manual page (man fzf)
• [x] I have the latest version of fzf: 0.32.1 (4993d19)
• [x] I have searched through the existing issues

Info

• OS=Windows11
• Shell=pswh 7.2.5 on Windows Terminal or conhost

Problem / Steps to reproduce

Cyrillic string typed into fzf is rendered as ??? and the search doesn't work. But when the same search string is passed as -q argument fzf is able to use what was passed in the -q argument. After some debugging I found out that this problem only occurs if height parameter is used (console output is redacted a bit for readability here).

» $env:FZF_DEFAULT_OPTS = $null
» fzf -q "алиса" --height 60%

> алиса
> Алиса и дракон\Folder.jpg
  Алиса и притворщики\Folder.jpg
  Алиса и дракон\Alisa_i_drakon.mp3

» $env:FZF_DEFAULT_OPTS = $null
» fzf --height 60%

> ?????

» $env:FZF_DEFAULT_OPTS = $null
» fzf

> алиса
> Алиса и дракон\Folder.jpg
  Алиса и притворщики\Folder.jpg
  Алиса и дракон\Alisa_i_drakon.mp3

[kelleyma49]

I believe this is an issue with the fact that the method for reading characters using the light renderer isn't supported (yet). I believe this issue is relevant: https://github.com/microsoft/terminal/issues/7777.

The fullscreen version (meaning, not using the --height parameter) uses https://github.com/gdamore/tcell, which uses native Windows functions to read input.

[FallenGameR]

I believe this is an issue with the fact that the method for reading characters using the light renderer isn't supported (yet). I believe this issue is relevant: https://github.com/microsoft/terminal/issues/7777.

This shouldn't be the case. The error is reproducible in conhost. So it is not Windows Terminal specific.

[kelleyma49]

I believe this is an issue with the fact that the method for reading characters using the light renderer isn't supported (yet). I believe this issue is relevant: microsoft/terminal#7777.

This shouldn't be the case. The error is reproducible in conhost. So it is not Windows Terminal specific.

See below. The issue I referenced is referenced in the Microsoft documentation discussing the limitations of using virtual terminal sequences. My interpretation of the Microsoft docs and my empirical evidence demonstrate that using the standard ReadFile functions with a console only works with ASCII input.

Support on the input stream varies depending on the input mode and will continue to improve over time. Notably the default "cooked" modes on input do not fully support UTF-8 yet. The current status of this work can be found at [Microsoft/terminal#7777 (https://github.com/microsoft/terminal/issues/7777) on GitHub. The workaround is to use the algorithmically-translatable UTF 16 for reading input through ReadConsoleW or ReadConsoleInputW until the outstanding issues are resolved.

https://docs.microsoft.com/en-us/windows/console/classic-vs-vt