Search results overflowing into search input field

[akrifari]

Description

Hello fzf-lua's maintainer, thanks for creating this plugin it is a real joy to use so far. Sadly, I stumbled upon this issue while I was searching for something using :FzfLua grep and apparently the search results somehow overflowing into search input field. I am not sure what is the root cause of this problem as there are no weird characters in the files (unless you take those emojis into account). Let me know if you need any additional information.

Screencast

Peek.2021-12-24.mp4

Configuration

fzf-lua config

fzf_lua.setup {
  winopts = {
    fullscreen = true,
  },
  keymap = {
    builtin = {
      ["<f2>"]  = "toggle-fullscreen",
      ["<f3>"]  = "toggle-preview-wrap",
      ["<f4>"]  = "toggle-preview",
      ["<f5>"]  = "toggle-preview-ccw",
      ["<f6>"]  = "toggle-preview-cw",
      ["<c-f>"] = "preview-page-down",
      ["<c-b>"] = "preview-page-up",
    },
    fzf = {
      ["alt-a"]  = "toggle-all",
      ["ctrl-k"] = "half-page-up",
      ["ctrl-j"] = "half-page-down",
      -- only valid with fzf previewers (bat/cat/git/etc)
      ["f3"]     = "toggle-preview-wrap",
      ["f4"]     = "toggle-preview",
      ["ctrl-f"] = "preview-page-down",
      ["ctrl-b"] = "preview-page-up",
    },
  },
  fzf_opts = {
    ['--layout'] = 'default',
  },
  previewers = {
    git_diff = {
      pager = "delta",
    },
  },
  git = {
    files = {
      multiprocess = true,
    },
    commits = {
      cmd = "git log --pretty=format:'%C(auto)%h%d %s %C(green)%cr' --color",
      fzf_opts = {
        ['--layout'] = 'reverse',
      }
    },
    bcommits = {
      cmd = "git log --pretty=format:'%C(auto)%h%d %s %C(green)%cr' --color"
    }
  },
  builtin = {
    winopts = {
      fullscreen = false
    }
  },
  files = {
    multiprocess = true,
    winopts = {
      preview = {
        hidden = 'hidden'
      }
    },
    git_icons  = false,
    file_icons = false,
  },
  grep = {
    multiprocess = true,
    search       = "",
    file_icons   = false,
    git_icons    = false,
  },
}

.ripgreprc

--no-ignore-vcs
--column
--hidden

fzf config on .zprofile

export FZF_DEFAULT_COMMAND="rg --files"
export FZF_DEFAULT_OPTS=$FZF_DEFAULT_OPTS'
--no-height
--no-reverse
--color=dark
--color=fg:-1,bg:-1,hl:#5fff87,fg+:-1,bg+:-1,hl+:#ffaf5f
--color=info:#af87ff,prompt:#5fff87,pointer:#ff87d7,marker:#ff87d7,spinner:#ff87d7
--bind ctrl-b:preview-half-page-up,ctrl-f:preview-half-page-down
--bind ctrl-/:toggle-preview,ctrl-]:toggle-preview-wrap
'
export FZF_PREVIEW_OPTS="(bat {} || tree -C {}) 2> /dev/null"
export FZF_ALT_C_OPTS="--preview '$FZF_PREVIEW_OPTS'"
export FZF_CTRL_T_OPTS="--preview '$FZF_PREVIEW_OPTS'"
export FZF_CTRL_R_OPTS="--preview 'echo {}' --preview-window down:hidden:wrap"
export RIPGREP_CONFIG_PATH="$HOME/.ripgreprc"

Current workaround

Change preview window layout on top of fzf window/toggle preview window.

[ibhagwan]

Tysm for this very detailed and well explained report!

The way I see it there could be two causes for this:

• First possible cause is the new multiprocess option, can you try with mutliprocess = false and see if this still happens?

• Second option is the use of --info=inline in fzf, can you add the below to your current fzf_opts and test?

fzf_opts = {
    ['--info'] = 'default',
    ['--layout'] = 'default',
  },

The reason for the latter is the recent discovery of a rendering bug with --info=inline with fzf, junegunn/fzf#2692, it was fixed a couple of days ago and will be released with 0.29.0.

If both don't work I would be interested to see if this bug also exists with skim, once installed just add fzf_bin = 'sk' to your config and everything else should work out of the box, this can give us a lead whether the issue lies in fzf-lua or fzf itself.

[ibhagwan]

junegunn/fzf#2482 - this could also be related, what is your fzf --version?

[akrifari]

Thanks for your quick response!

The way I see it there could be two causes for this:

• First possible cause is the new multiprocess option, can you try with mutliprocess = false and see if this still happens?

• Second option is the use of --info=inline in fzf, can you add the below to your current fzf_opts and test?

fzf_opts = {
    ['--info'] = 'default',
    ['--layout'] = 'default',
  },

Here is the results:

1. First method, still got the same results after disabling multiprocess.
2. Second method (with ['--info'] = 'default'), still got the same results sporadically (sometimes it is overflowing search index matches, sometimes it is overflowing search input field).
3. Third method (with ['--info'] = 'inline'), still got the same results.

The reason for the latter is the recent discovery of a rendering bug with --info=inline with fzf, junegunn/fzf#2692, it was fixed a couple of days ago and will be released with 0.29.0.

Thanks for the explanation and the pointer. I will take a look.

If both don't work I would be interested to see if this bug also exists with skim, once installed just add fzf_bin = 'sk' to your config and everything else should work out of the box, this can give us a lead whether the issue lies in fzf-lua or fzf itself.

The search input field is happy now with skim.

what is your fzf --version?

I am on 0.28.0 (e4c3ecc).

[ibhagwan]

Thank you once again the detailed reply, since the behavior is the same regardless of multiprocess and also the fact it does work well with sk, I'm leaning towards an upstream fzf issue which will hopefully be resolved with 0.29.0.

We can leave this issue open until we figure out if 0.29.0 solves it or if we learn something new, it would be helpful if you can figure out what causes this exactly (emojis perhaps?), would also be interesting to see if this is reproduceable at the shell level (i.e. without neovim or fzf-lua), to do so you can run :FzfLua grep debug=true, that will generate the exact underlying rg command as the first result line, you can then copy the command and run it in the shell, i.e. rg ... | fzf --ansi and see if you get the same behavior in the shell.

If you can reproduce it in the shell it's definitely an upstream issue.

The search input field is happy now with skim.

At least you have an alternative for now!

[nyngwang]

If both don't work I would be interested to see if this bug also exists with skim, once installed just add fzf_bin = 'sk' to your config and everything else should work out of the box, this can give us a lead whether the issue lies in fzf-lua or fzf itself.

I don't recommend using skim. I once switched to it when debugging #247 and it caused my computer to reach a higher peak temperature (from ~80 to 90+ Celsius) than the default option, with less time. It seems to consume more energy and thus shorten the battery life.

I am not sure what is the root cause of this problem as there are no weird characters in the files (unless you take those emojis into account)

I encountered a similar issue before with Chinese filenames, i.e. the input area got broken after some special characters are shown in the result list. So I think you're in the right direction: the root cause is probably related to emojis/encodings.

(@ibhagwan I hope this info will help you debugging.)

[ibhagwan]

Hi @akrifari, 0.29.0 was released a few days ago, can you try it and let me know if this solves your issue?

Can be downloaded from fzf's releases.

[akrifari]

Sorry for the lack of response. I have been caught up in real life for the last couple of days.

If you can reproduce it in the shell it's definitely an upstream issue.

Just to make sure, if I can reproduce this at the shell level (without rg, just fzf < filename.ext) by an upstream issue you were referring to fzf, right? @ibhagwan.

---

I don't recommend using skim. I once switched to it when debugging #247 and it caused my computer to reach a higher peak temperature (from ~80 to 90+ Celsius) than the default option, with less time. It seems to consume more energy and thus shorten the battery life.

Thanks @nyngwang for the heads up 👍. I will reconsider it.

[ibhagwan]

Sorry for the lack of response. I have been caught up in real life for the last couple of days.

There's no rush here on Github world, take your time and reply when life won't get in your way :-)

Just to make sure, if I can reproduce this at the shell level (without rg, just fzf < filename.ext) by an upstream issue you were referring to fzf, right? @ibhagwan.

Correct, although I would probably test the same rg command instead of < filename, more chances of this being reproduced.

That said, I would try 0.29.0 before anything else as this might have been solved already.

[akrifari]

After creating minimal reproducible file, I am 100% sure the culprit are those emojis. Thanks @ibhagwan and @nyngwang I would not have made it this far without you. For those interested, this is the reproducible file:

repro.md

Sit quos enim architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem
Sit quos enim architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem
👧🏼 Sit quos enimo architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem
Sit quos enim architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem
Sit quos enim architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem
👧🏼 Sit quos enimo architecto nobis quas. Sequi dicta aut totam debitis neque ipsa! Est corrupti ea dolorum molestias ea Totam magni magnam maxime optio incidunt? Ipsum sapiente recusandae animi voluptatem

---

Context

• fzf version 0.29.0 (dc975e8)
• Neovim version 0.6.0
• Alacritty version 0.9.0 (fed349aa)
• Kitty version kitty 0.23.1

Test Scenarios (shell level)

1. Run alacritty --config-file=/dev/null or kitty --config=/dev/null.
2. Run rg --column --line-number --no-heading --color=always --smart-case --max-columns=512 'enim' | fzf --ansi or rg --column --line-number --no-heading --color=always --smart-case --max-columns=512 'enim' | fzf --ansi --info=inline.

Test Scenarios (fzf-lua)

1. Run alacritty --config-file=/dev/null or kitty --config=/dev/null.
2. Open Neovim.
3. Run :FzfLua grep enim.

Screencasts

• Alacritty shell level
• fzf-lua in Alacritty
• Kitty shell level
• fzf-lua in Kitty

Results

After testing it in two different terminal emulators surprisingly I got strange results.

• Alacritty:
  • Shell level did not work ❌.
  • fzf-lua did not work ❌.
• Kitty:
  • Shell level works ✔️.
  • fzf-lua did not work ❌.

I am wondering this is not really about an fzf issue, per se. It might be related how Neovim renders emoji ¹ and how terminal emulators handle that as well ²³. What do you think?

Footnotes

1. https://github.com/neovim/neovim/issues/7151 ↩

2. https://github.com/alacritty/alacritty/issues/3975 ↩

3. https://github.com/kovidgoyal/kitty/issues/3810 ↩

[ibhagwan]

@akrifari interesting issue, it does seem pretty clear that it's emoji related and also that there's probably not much I can do within fzf-lua to mitigate that.

Now the quesion is whether this is a terminal issue or an fzf issue, the fact it works in kitty at the shell level leads me to think it's more terminal related than fzf, especially with the linked issues from both neovim and alacritty related to emojis.

There's a good chane though that this can also be mitigtaed at the fzf level, it might be worth it to open an issue with fzf so we have it tracked or better yet solved, I will open an issue with fzf.

[ibhagwan]

junegunn/fzf#2697 opened an issue upstream, since this is most likely not an issue with fzf-lua I'm going to close this unless proven otherwise.

[akrifari]

Thank you for bearing with me! Have a great day.