FZF list buggy sometimes

[Prashanthvsdvn]

ISSUE: When using ytfzf with fzf, sometimes the fzf menu is buggy. The list rewrites as you scroll down and up leading to fzf's first line keep shifting down. I am not sure what the cause is. I have attached a screencapture for reference.

ytfzf_bug.mp4

[Euro20179]

This happens to me as well, I'm not exactly sure why it happens but I think it's because of unicode (mainly emoji) characters. Since this is a bug with fzf it might be worth sending a bug report to them.

[Prashanthvsdvn]

Yeah I can do that. But before that I want to check the data upon which fzf acts. There are 2 important points why I think the data being sent should be checked before filing it to fzf.

1. I dont think I had any search results with emojis in my search result in my video I uploaded (I have no idea why it got corrupted), so I think it is not the case of emojis making fzf go crazy.
2. Secondly, this bug happens only rarely, even when searching the same query. If it was due to unicode characters, I would expect it to mess up every single time there was emoji but that is not the case.

All of this got me thinking that something in the data fed to fzf has the underlying problem that makes fzf go ham. I did not go through the script thoroughly but I think I did see multiple User Agent being fed for curl argument. Could there be a variance in results when different user agent is used. I mean, I could be wrong that, it might youtube once in a while gets its screw loose but this seems something that we can investigate first, before filing it to fzf.

Also, I have no clue why the video got corrupted. I'll try capturing the output again and reupload it.

[Euro20179]

could there be a variance in results when different user agent is used

There could be, but I don't think it matters, as I believe it's the name of the videos messing up fzf.

Secondly, this bug happens only rarely, even when searching the same query. If it was due to unicode characters, I would expect it to mess up every single time there was emoji but that is not the case.

It happens consistently with the same videos, so if you can get the same videos that break it to show up, it will always break.

I dont think I had any search results with emojis in my search result in my video I uploaded (I have no idea why it got corrupted), so I think it is not the case of emojis making fzf go crazy.

I think it's about unicode characters that look like 1 character, but are technically 2 characters, for example: all flag emojis are 2 characters but look like 1.

I did ytfzf russiafewa to get the results below,

Whenever i go over them the screen redraws weirdly.

Whole image

I took 3 of the results, one of which being the unicode one, and piped it into fzf again and it's still broken

(oddly enough the bug seems to not happen with less than or equal to 2 results)

This may be confirmation bias, however I have yet to see an example (personally) where this bug happens and there aren't unicode characters.

[pystardust]

Which terminal emulators are you guys using? I face similar issues with hindi text on st, but when using it with other terminals like kitty the problem doesn't occur. I have heard a lot of issues with st rendering hindi fonts in general

[Euro20179]

Which terminal emulators are you guys using

I have had the problem in kitty and alacritty

[Prashanthvsdvn]

I have used st in the video but I had problems with alacritty as well. I am not sure about hindi text but I had problems with english text itself.

[kevenwyld]

I'm having this issue as well. Here's a short video of the problem, as well as a screenshot from youtube of the title causing the issue:

ytfzf_unicode_bug-2022-08-02_21.57.17.mp4

I'm using alacritty as my terminal emulator and the ytfzf-git package on archlinux version r1606.ae1cbfd-1

Let me know if you'd like me to test anything, and thank you for all your work on this project!

[kevenwyld]

It looks like this is because of alacritty/alacritty#3975 which actually affects several terminal emulators not just alacritty. It seems to cause an issue where two characters are rendered on screen for both the emoji and the modifier (color or tone in this case) but only take up one column. So the number of columns doesn't match what is displayed.

[Euro20179]

Nice job on finding an exact issue to point to.

In my testing, kitty is the only terminal that this bug doesn't happen with, and someone in that bug report mentions that kitty handles utf-8 character widths differently.

[kevenwyld]

Kitty has a slightly different but "better" (I guess) graphical issue. Instead of displaying 1 too many columns, or messing up the newline at the end, it displays 1 too few. At least with this particular set of titles and emoji. It doesn't mess up scrolling or searching though so that's nice.

I suppose one could work around it if fzf, or ytfzf implemented an option or flag to strip emojis. It wouldn't completely solve the problem as this original issue is about non-emoji chars, but I suppose it might help a little. I might give this a try later on, there are a few options but matching and stripping emojis in general seems to be a bit of a moving target.

[Euro20179]

Instead of displaying 1 too many columns, or messing up the newline at the end, it displays 1 too few

This gave me an idea, what if i tried reducing the maximum width of fzf, so that it doesn't overflow because the terminal is too small. I dug around the fzf manpage and found --margin, you can run FZF_DEFAULT_OPTS='--marin=0,10,0,0' ytfzf ... and it will fix overflowing. Ofcourse it will still look a bit weird however it doesn't break scolling.

According to the manpage --margin works like this --margin=top-margin,right-margin,bottom-margin,left-margin

[kevenwyld]

@Euro20179 thanks! That works great and doesn't require code changes. Seems like other than a workaround the best we can hope for is better emoji modifier handling in general for terminal emulators.