chars in last preview exists in the next

[timsu92]

Version

• fzf: 0.33.0 installed using Git
• fzf-git.sh: commit e44dfb3
• bat: 0.21.0 installed using bat_0.21.0_amd64.deb
• OS: Ubuntu 22.04.1 LTS on WSL2
• Terminal: Windows Terminal

Step to reproduce

1. ctrl-G ctrl-F
2. Move cursor onto a file which has words long enough in the preview window.
3. Move cursor onto another file whose preview produced by bat overlaps in terminal with the output of last file.

expected behavior

Preview of the "another file" only

actual behavior

• In the header and footer of bat's production, it shows the preview result of last file if the header is shorter in width. Plus, the char before "File" and "Size" is doing the same.
• In the content of the newly previewing file, there are two spaces in each line locates between the gridline differentiating line number and content and content. And the first space shows whatever it was in the last preview.

  first file

  

  "another file"

  

[junegunn]

Is the problem still reproducible when you set

_fzf_git_cat="bat --style=numbers --color=always --pager=never"

I'm trying to see if it's caused by the way your terminal emulator displays Unicode box-drawing characters bat uses.

[timsu92]

No, this issue can be solved by both your shell var and _fzf_git_cat="bat --style=numbers --color=always". But removing --style=numbers will cause the problem.

[timsu92]

BTW, --color=always is required, or the line numbers will gone, which isn't doing the same with bat <filename> --style=numbers --color=never

[junegunn]

So how does this render on your terminal? Are the ends of the horizontal lines aligned with .md, or are the lines shorter than they look on this page?

cat << EOF
───────┬────────────────
       │ File: README.md
───────┼────────────────
EOF

If they are shorter, it explains why some characters are not properly cleared on the preview window. fzf calculates the width of each character of a line and only clears the remaining line after the last character.

[timsu92]

It seems that they aren't shorter🤔

I copied them line-by-line at first and them copied them as a whole.

[timsu92]

@junegunn May I confirm whether spaces you sent me were actually spaces? I'm afraid if there's something different induced by the clipboard.

[junegunn]

Yes.

I was wondering why the horizontal lines in your screenshot are so short, taking only half the width of the preview window.

fzf --preview 'bat --color=always {}' looks like this on my machine.

[timsu92]

I'm not sure though. I get this by fzf --preview 'bat --color=always {}':

I see you use a font other than mine in other issue. Would that be the cause? I use JetBrainsMono NerdFont. What's yours? Is there a link?

Situation with other fonts

In Windows Terminal, there are several fonts preinstalled. Most of them show like mine, except for these which currupts a lot of borders:

Click to see how those fonts doing

### LiSu  ### MS Gothic  ### NSimSun  ### YouYuan 

[timsu92]

Nonetheless, I find it interesting that no matter which font I use, the line number in the upper-right cornor is always in the right position. Maybe it would be nice to use variable regarding to that?

[junegunn]

Can you test this again with the latest version of fzf and see if anything's changed?

Excerpt from 0.36.0 changelog:

• Better support for (Windows) terminals where each box-drawing character takes 2 columns. Set RUNEWIDTH_EASTASIAN environment variable to 1.

[timsu92]

Unfortunately, no😭 Neither the original problem nor the length of horizontal lines. I'm on fzf V0.38.0 and most recent fzf-git and NerdFont V2.3.3 (JetBrains Mono Regular Nerd Font Complete Windows Compatible)

Althought I didn't see any difference between leaving RUNEWIDTH_EASTASIAN unset and setting it 1, searching this I see other people talk about system language settings, and I see difference! I set my Ubuntu to zh_TW.UTF-8, and both above problems and yet other problems (the border isn't bonding the preview window and there are dashes) shows: However, if I switch to en_US.UTF-8, problems are gone! There's only a line I'm not understanding it's meaning.

But I really love to use my system in Chinese...

[timsu92]

Excerpt from 0.36.0 changelog:

On Vim, the variable will be automatically set if &ambiwidth is double

But this var in my Vim is single, and changing it to double will break status line, which is rendered by powerline. This change allows fzf window to show in a currect size, but the horizontal lines will be in dashes.

[junegunn]

This issue is pretty old. Do you still have the problem with the latest version of fzf?

[timsu92]

Sorry I temporarily can't setup fzf with bat. I'll try again later