lua/fzf-lua/win.lua:296: attempt to index a nil value on master

[fsouza]

I believe this was introduced on eefed45, likely because I'm customizing winopts here: https://github.com/fsouza/dotfiles/blob/85d807163e0b380ddc067c9d170c29f39de95817/nvim/lua/fsouza/fzf-lua.lua#L63

I'll try to send a PR fixing it later 😁

[ibhagwan]

You are correct, the new window requires all 8 border chars as it draws the border manually, I fixed the win_border = true case and absolutely forgot about the false case, I’ll fix it properly today but for now I believe sending an array of 8 empty characters would get you the result you want (no border).

Alternatively you can go back to the old previewer by setting default_previewer = “bat”.

[ibhagwan]

Just tested it and I have a question for you: with the new built in previewer where the preview window is a separate window - does it even make sense to have no border?

It looks so weird and not intuitive UI at all. I can make the no border apply to the fzf window and keep the border for the preview window (especially important since it has title/scrollbar as well as an option to expand in size) but then again it looks quite awful.

If you give me some input on what is the look you’re after (with the the builtin previewer) I’ll do my best to accommodate while keeping it usable.

[ibhagwan]

Should be fixed in the latest commit, the way it works is as follows:

The false value is now backwards compatible, when win_border = false the fzf window to no border and will keep the preview window with the default border. If you'd like to have no borders on both windows (not usable IMO but up to you) just pass an array of 8 empty characters:

  winopts = {
      win_border       = { ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ' }
  }

Note that by default the builtin previewer will also draw a title and scrollbar so you might want to get rid of those as well by setting:

  previewers = {
    builtin = {
      title = false,
      scrollbar = false,
    }
  }

[ahmedelgabri]

I have the same issue but for a different reason, I use a tool to encrypt some files in my dotfiles repo. Right now it prints some warnings that I can't suppress. elasticdog/transcrypt#55

So the split call here will return a list with a single item

fzf-lua/lua/fzf-lua/core.lua

Line 97 in 2315413

local split = vim.split(status[i], " ")

which means that this will be set the value to nil

fzf-lua/lua/fzf-lua/core.lua

Line 98 in 2315413

diff_files[split[2]] = split[1]

. The solution is to wrap this line

fzf-lua/lua/fzf-lua/core.lua

Line 98 in 2315413

diff_files[split[2]] = split[1]

with a check to make sure split size is always more than 1 and only set diff_files if the condition is true.

[ibhagwan]

I have the same issue but for a different reason, I use a tool to encrypt some files in my dotfiles repo. Right now it prints some warnings that I can't suppress. elasticdog/transcrypt#55

So the split call here will return a list with a single item

fzf-lua/lua/fzf-lua/core.lua

Line 97 in 2315413

local split = vim.split(status[i], " ")

which means that this will be set the value to nil

fzf-lua/lua/fzf-lua/core.lua

Line 98 in 2315413

diff_files[split[2]] = split[1]

. The solution is to wrap this line

fzf-lua/lua/fzf-lua/core.lua

Line 98 in 2315413

diff_files[split[2]] = split[1]

with a check to make sure split size is always more than 1 and only set diff_files if the condition is true.

I see, is there anyway I can reproduce this myself and maybe come up with a more robust regex as a solution?

Btw, this has no relation to this issue, this bug only affects the git icons and wasn’t introduced with the latest commit, maybe it’s better we open a new issue for this?

[ahmedelgabri]

I see, is there anyway I can reproduce this myself and maybe come up with a more robust regex as a solution?

I think you can set up a demo git repo & set up transcrypt inside of it, then make a change to a committed encrypted file. This should trigger the warning (I hope, because it might depend on the OpenSSL version)

For regex, I think a good start maybe would be something like this /^(M|U|D|A|R)\s(.*)/g

Btw, this has no relation to this issue, this bug only affects the git icons and wasn’t introduced with the latest commit, maybe it’s better we open a new issue for this?

I posted it here because I had the same exact error at nearly the same line too

[fsouza]

Just tested it and I have a question for you: with the new built in previewer where the preview window is a separate window - does it even make sense to have no border?

First, thank you very much for the quick fix. Second, sorry for my bad report, I guess I was misusing it. I didn't realize the default previewer had changed! I agree it doesn't make sense to have no border with the built-in previewer.

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

[ibhagwan]

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

Let me know what you think, since the buffers previewer was lacking (wasn’t using bat, no syntax support) I changed the default buffers previewer to the new one so you can get a feel for it there.

[ibhagwan]

I see, is there anyway I can reproduce this myself and maybe come up with a more robust regex as a solution?

I think you can set up a demo git repo & set up transcrypt inside of it, then make a change to a committed encrypted file. This should trigger the warning (I hope, because it might depend on the OpenSSL version)

For regex, I think a good start maybe would be something like this /^(M|U|D|A|R)\s(.*)/g

Btw, this has no relation to this issue, this bug only affects the git icons and wasn’t introduced with the latest commit, maybe it’s better we open a new issue for this?

I posted it here because I had the same exact error at nearly the same line too

Tysm for the info I’ll do some testing and update you, I still believe the two issues are unrelated, can you let me know if you’re still getting this error (you shouldn’t) and if not open a new issue just for good measure?

[fsouza]

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

Let me know what you think, since the buffers previewer was lacking (wasn’t using bat, no syntax support) I changed the default buffers previewer to the new one so you can get a feel for it there.

Just tried it and it looks great! I guess one thing that I'm missing is the ability to highlight the line in the preview (for example when using grep or lsp_references). Do I need to use some special highlight group?

[fsouza]

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

Let me know what you think, since the buffers previewer was lacking (wasn’t using bat, no syntax support) I changed the default buffers previewer to the new one so you can get a feel for it there.

Just tried it and it looks great! I guess one thing that I'm missing is the ability to highlight the line in the preview (for example when using grep or lsp_references). Do I need to use some special highlight group?

Sorry just read the docs and saw thathl_range will be supported one day.

I just tried it with buffers and it looks much better! Will definitely change the default once hl_range is implemented. Let me know if I can help in any way :)

[ibhagwan]

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

Let me know what you think, since the buffers previewer was lacking (wasn’t using bat, no syntax support) I changed the default buffers previewer to the new one so you can get a feel for it there.

Just tried it and it looks great! I guess one thing that I'm missing is the ability to highlight the line in the preview (for example when using grep or lsp_references). Do I need to use some special highlight group?

Sorry just read the docs and saw thathl_range will be supported one day.

I just tried it with buffers and it looks much better! Will definitely change the default once hl_range is implemented. Let me know if I can help in any way :)

Range would be when a match range was found (perhaps just for LSP ranges?), for now the line is highlighted using the default CursorLine highlight of your color scheme, I can add a highlight config option for that if that would help?

For reference, check out the below screenshot, the highlighted line (black bg) should be the grep/rg search match and if a column is specified and is > 1, the cursor will also be highlighted (light blue bg, column 7) on the right side.

Note that the left line (247) doesn’t match the preview line (343) because I scrolled down inside the preview using S-down.

[fsouza]

For now I changed the default to bat, but I'll give the new previewer a shot too! :D

Let me know what you think, since the buffers previewer was lacking (wasn’t using bat, no syntax support) I changed the default buffers previewer to the new one so you can get a feel for it there.

Just tried it and it looks great! I guess one thing that I'm missing is the ability to highlight the line in the preview (for example when using grep or lsp_references). Do I need to use some special highlight group?

Sorry just read the docs and saw thathl_range will be supported one day.
I just tried it with buffers and it looks much better! Will definitely change the default once hl_range is implemented. Let me know if I can help in any way :)

Range would be when a match range was found (perhaps just for LSP ranges?), for now the line is highlighted using the default CursorLine highlight of your color scheme, I can add a highlight config option for that if that would help?

For reference, check out the below screenshot, the highlighted line (black bg) should be the grep/rg search match and if a column is specified and is > 1, the cursor will also be highlighted (light blue bg, column 7) on the right side.

Note that the left line (247) doesn’t match the preview line (343) because I scrolled down inside the preview using S-down.

Ohhh I see. The problem is that I had cursorlineopt=number. Is there a way to set cursorlineopt=both just in the preview window?

[ibhagwan]

Ohhh I see. The problem is that I had cursorlineopt=number. Is there a way to set cursorlineopt=both just in the preview window?

Definitely, the preview window has it’s own set of curated window options, I’ll add this option later so it’s always visible as well as the option to change its highlight.

Edit: unfortunately I need to head out, I’ll make sure this is added tonight and post here once I do.

Edit 2: technically what you’re asking is already possible using the deprecated setting winopts.window_on_create, if you set it to a function it will be run upon window creation and you can just set the below but as I mentioned the fix would be here sooner than later.

  winopts = {
    window_on_create = function() vim.cmd(“setlocal cursorlineopt=both”) end
  }

[fsouza]

No rush! Thanks for the quick interactions! I sent #61 defining the option :D

[ibhagwan]

FYI, the latest commit added the option to set the highlight for the CursorLine, take a look at previewers.builtin.hl_cursorline.