Search results overflowing into search input field #275

akrifari · 2021-12-24T10:53:26Z

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.

The text was updated successfully, but these errors were encountered:

ibhagwan · 2021-12-24T11:21:33Z

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 · 2021-12-24T11:27:11Z

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

akrifari · 2021-12-24T13:02:34Z

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:

First method, still got the same results after disabling multiprocess.
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).
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 · 2021-12-24T13:20:27Z

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 · 2021-12-24T18:56:07Z

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 · 2021-12-27T17:59:49Z

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 · 2021-12-28T03:58:15Z

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 · 2021-12-28T12:36:48Z

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 · 2021-12-28T14:34:43Z

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)

Run alacritty --config-file=/dev/null or kitty --config=/dev/null.
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)

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

Screencasts

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?

ibhagwan · 2021-12-28T21:35:59Z

@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 · 2021-12-28T21:54:29Z

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 · 2021-12-29T10:31:00Z

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

ibhagwan added the invalid This doesn't seem right label Dec 24, 2021

ibhagwan mentioned this issue Dec 28, 2021

Search results overflow into search input field on some terminals when text contains emojis junegunn/fzf#2697

Open

10 tasks

ibhagwan closed this as completed Dec 28, 2021

ibhagwan mentioned this issue Dec 31, 2021

The results of FzfLua files overflow on Ubuntu 20.04 with Fzf version 0.29.0 and 0.24.3 #287

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Search results overflowing into search input field #275

Search results overflowing into search input field #275

akrifari commented Dec 24, 2021

ibhagwan commented Dec 24, 2021 •

edited

Loading

ibhagwan commented Dec 24, 2021

akrifari commented Dec 24, 2021

ibhagwan commented Dec 24, 2021

nyngwang commented Dec 24, 2021 •

edited

Loading

ibhagwan commented Dec 27, 2021

akrifari commented Dec 28, 2021

ibhagwan commented Dec 28, 2021

akrifari commented Dec 28, 2021

ibhagwan commented Dec 28, 2021

ibhagwan commented Dec 28, 2021

akrifari commented Dec 29, 2021

Search results overflowing into search input field #275

Search results overflowing into search input field #275

Comments

akrifari commented Dec 24, 2021

Description

Screencast

Configuration

Current workaround

ibhagwan commented Dec 24, 2021 • edited Loading

ibhagwan commented Dec 24, 2021

akrifari commented Dec 24, 2021

ibhagwan commented Dec 24, 2021

nyngwang commented Dec 24, 2021 • edited Loading

ibhagwan commented Dec 27, 2021

akrifari commented Dec 28, 2021

ibhagwan commented Dec 28, 2021

akrifari commented Dec 28, 2021

Context

Test Scenarios (shell level)

Test Scenarios (fzf-lua)

Screencasts

Results

Footnotes

ibhagwan commented Dec 28, 2021

ibhagwan commented Dec 28, 2021

akrifari commented Dec 29, 2021

ibhagwan commented Dec 24, 2021 •

edited

Loading

nyngwang commented Dec 24, 2021 •

edited

Loading