What is the buffer type of fzf windows and how to prevent it from being conflated with regular terminals?

[shmerl]

I encountered an edge case. I'm developing a color theme that allows falling back to user's terminal colors for neovim terminals, which I detect with using this type of check

if (vim.bo.buftype == "terminal")

I implemented various conditions with autocmd (see above link) that catch switching in and out of the terminal for windows and buffers. That generally works, but I noticed that fzf windows started being treated as a terminal in this regard.

Is there some way to prevent that or may be to refine my check to avoid that collision?

[shmerl]

Hm, may be matching vim.api.nvim_buf_get_name(0) to ^term:// could limit things?

[shmerl]

That didn't help:

local is_terminal = (vim.bo.buftype == "terminal") and vim.api.nvim_buf_get_name(0):find('^term://')

It still matches fzf lua windows.

[shmerl]

OK, I figured out one way to do it:

local is_terminal = (vim.bo.buftype == "terminal") and (vim.o.filetype == "")

since filetype for fzf buffer is set to fzf. I'll think whether to make this configurable explicitly, but at least it worked.

[shmerl]

Heh, now I hit another issue. I reset colors to default in my them for terminals like this:

vim.g.terminal_color_0 = nil
vim.g.terminal_color_1 = nil
...
vim.g.terminal_color_15 = nil

But I need to prevent that from affecting fzf-lua windows...

[shmerl]

I arrived to something like this:

  local function is_normal_terminal()
    return (vim.bo.buftype == "terminal") and (vim.o.filetype == "")
  end

  vim.api.nvim_create_autocmd({ 'TermOpen', 'TermEnter' }, {
    pattern = { "*" },
    callback = function()
      vim.schedule(function()
        if not is_normal_terminal() then
          for term_color, value in pairs(<...table_of_theme_terminal_colors...>) do
            vim.g[term_color] = value
          end
        end
      end)
    end,
    desc = "handling special terminals with theme's colors"
  })

Where term_color is from terminal_color_0 to terminal_color_15.

That sort of works but weirdly. When I open fzf's custom grep command, it doesn't work at first try, but works at all subsequent ones:

:lua require('fzf-lua').live_grep_native({ cmd = "rg" })

If I change vim.g (which is weird above to change globally) to vim.b it doesn't work at all. Do you have any suggestions how to handle this?

[shmerl]

Also asked this: neovim/neovim#37517

[shmerl]

Here is my current approach: https://gitlab.com/shmerl/neogotham/-/blob/main/lua/neogotham/theme.lua?ref_type=heads#L162

It mostly works except the above problem, but I suspect there might be some bug in fzf-lua that affects that first time invocation.

[shmerl]

@ibhagwan: Can you please suggest if it's possible to solve? Or may be it's better to open a bug about it? I think I'm hitting this kind of problem:

In order to detect fzf-lua's window, I'm catching TermOpen event. At that point unfortunately there is no filetype set but it's the only point at which changing buffer specific terminal colors works (i.e.vim.b[buf_id].terminal_color_...).

Postponing that to later time with vim.schedule or with TermEnter blocks color changes somehow.

So what is the correct way to do it?

See more discussion here.

[ibhagwan]

Another approach you can explore is setting:

winopts = {
  on_create = function(e)
    vim.b[e.buf].local_var = true
  end
}

and then test if the local var is set in your TermOpen, since on_create is called before fzf is started it might be what you need.

[shmerl]

TBH I’m not sure what you’re trying do fully, is it just to exclude fzf-lua windows?

Yes, I want to handle special terminals (like fzf lua's) differently from regular terminal windows.

If so the buf filetype is set to fzf as soon as termopen is called, you can see it in the code here:

What I observe is that in this scenario, filetype is not set yet unless I postpone things, but postponing prevents setting colors:

  vim.api.nvim_create_autocmd({ 'TermOpen' }, {
    pattern = { "*" },
    callback = function(event)
      -- vim.bo.filetype is empty here even for fzf-lua's window!

  vim.api.nvim_create_autocmd({ 'TermOpen' }, {
    pattern = { "*" },
    callback = function(event)
      vim.schedule(function()
        -- vim.bo.filetype is `fzf` here but now it's too late to change colors!

[shmerl]

you’re trying to affect fzf-lua colors that’s another issue as Fzf override most of fzf’s colors

Mostly I'm trying to set terminal colors to theme's colors in case of unusual terminals, vs setting them to defaults (nil) which should produce user terminal's colors in most cases.

fzf-lua does adhere to that, but the problem is that I didn't find a clear way to detect fzf lua's terminal vs normal terminal.

That winopts is the configuration for fzf-lua itself?

I was trying to find some more generic solution, to basically catch "regular terminal windows" vs "unusual / plugin terminals". I guess there is no strict definition for the latter anyway.

[nenahp]

#2534

[ibhagwan]

fzf-lua does adhere to that, but the problem is that I didn't find a clear way to detect fzf lua's terminal vs normal terminal.

That's because fzf-lua is a "normal" terminal it just happens to run fzf

That winopts is the configuration for fzf-lua itself?

Yes

I was trying to find some more generic solution, to basically catch "regular terminal windows" vs "unusual / plugin terminals". I guess there is no strict definition for the latter anyway.

Your best bet is to mark the buffer beforehand in on_create, otherwise, before the fzf job is started why would there be any difference between fzf-lua and any other window/buffer?

[nenahp]

Another way is api.nvim_list_chans()[#api.nvim_list_chans()] to detect the "latest" job, then parse the argv.

[shmerl]

Since I'm doing it in a color theme, that would be too specific. I know that generally "normal" terminal has an empty file type, so catching non empty one is one way to generically detect something unusual without being too specific. Not a perfect solution but could work if like above, fzf would set the filetype early enough for TermOpen to catch it

[shmerl]

@nenahp: Neat, if that's acceptable and works (your PR), it could help my case.