With the same setup, non-ascii characters make Fzf quit; it's intricate

I found out that as soon as I removed the --height option from $FZF_DEFAULT_OPTS, fzf accepts non-ascii characters in Git Bash in Windows Terminal; however I could not make fzf work at all in Git bash.

Regarding the --height option, it's unfortunately set by almost all common commands, such as Ctrl-T.
The following lines, say in .bash_profile, remove it wherever possible:

  export FZF_DEFAULT_OPTS="${FZF_DEFAULT_OPTS//--height[=[:space:]][1-9][0-9]?/ }"
  export FZF_CTRL_T_OPTS="${FZF_CTRL_T_OPTS//--height[=[:space:]][1-9][0-9]?/ }"
  export FZF_CTRL_R_OPTS="${FZF_CTRL_R_OPTS//--height[=[:space:]][1-9][0-9]?/ }"

  export FZF_ALT_C_OPTS="${FZF_DEFAULT_OPTS} --preview='tree.com //F {} | tail +3 | head -\$LINES'"

Ideally, of course, the issue with setting --height in Fzf in Git Bash itself could be fixed.

You can just append --no-height at the end, because the last one wins.

export FZF_DEFAULT_OPTS="$FZF_DEFAULT_OPTS --no-height"

Thank you, I was not aware of it. This is more robust. Ideally, since the provided bash scripts set their own custom parameters, add a check for Git Bash, say by [ -z ${MSYSTEM+x} ] || ..., and append --no-height.

I can confirm that --no-height works for me too. In both Windows Terminal and mintty(from git bash).
BTW echo $FZF_DEFAULT_OPTS is empty so I suppose --height is the default, right?

Yes, you can inspect here:

https://github.com/junegunn/fzf/blob/0994d9c881f8380997b96bb0a4a7416b50bc2b0d/shell/key-bindings.bash

__fzf_defaults() {
  # $1: Prepend to FZF_DEFAULT_OPTS_FILE and FZF_DEFAULT_OPTS
  # $2: Append to FZF_DEFAULT_OPTS_FILE and FZF_DEFAULT_OPTS
  echo "--height ${FZF_TMUX_HEIGHT:-40%} --bind=ctrl-z:ignore $1"
  command cat "${FZF_DEFAULT_OPTS_FILE-}" 2> /dev/null
  echo "${FZF_DEFAULT_OPTS-} $2"
}


__fzf_select__() {
  FZF_DEFAULT_COMMAND=${FZF_CTRL_T_COMMAND:-} \
  FZF_DEFAULT_OPTS=$(__fzf_defaults "--reverse --walker=file,dir,follow,hidden --scheme=path" "${FZF_CTRL_T_OPTS-} -m") \

For me unability to input non-latin characters was introduced in 0.54, 0.53 works fine.

Did you try #3799 (comment) ?

Now I did, with no result. Will stick to 0.53 for a while.

If you're experiencing a change of behavior in 0.54.0, this might be the cause.

dca2262

See #3847 (comment)

I'll look into it when I get some time.

I can confirm that the LightRenderer for Windows written by @kelleyma49 cannot take Unicode characters.

When I type in a Unicode character, it reads it as ? (63).

Ideally, we should fix LightRenderer to support non-ASCII input, but I don't have the Windows expertise to do that, so I'm going to revert the decision I made in 0.54 to prefer LightRenderer over tcell-based renderer for now.

Related:

• Windows: Mouse-clicking doesn't work properly in bash #3847
• Windows: Added ReadConsoleInput functionality golang/sys#98

I believe I have a fix for reading and displaying non-ASCII input. Please see #3951

ReadConsoleW is the way to read Unicode input, accepting it as UTF16 which is the native Windows encoding for Unicode and is available starting in Windows NT and XP (so it's available in all currently supported versions of Windows).

Console Input Buffer has some info on how the input buffer works.

To read the full range of Unicode, surrogate pairs have to be handled. For example, code can't simply convert each UTF16 character individually into UTF8, because surrogate pairs are only a UTF16 encoding concept. Code needs to be aware of when a leading surrogate has been input, and then get the trailing surrogate and then convert them as a string from UTF16 to UTF8. Or convert them to UTF32 and then to UTF8.

Clink has some C++ code for handling surrogate pairs and converting from UTF16 to UTF8 for input here. Review that whole file for more context on reading full Unicode input in a Windows console. (Note that the mouse support doesn't generate proper ANSI escape codes for mount input -- it generates private internal-only custom escape codes for mouse input.)