[Feature]: Detach from the buffer when general.enable returns false

[lopi-py]

Problem

When using trouble, seems like general.enable gives a false positive (I also tried with my own function) so dropbar is attached, but on later calls, general.enable returns false

Expected behavior

The dropbar should be detached (if attached first) from the given buffer if general.enable returns false

[Bekaboo]

No, because that can accidently disable winbar set by other plugins, see #9. Instead you should improve the enable function in your config so that dropbar won't attach to Trouble windows. Let me know if you find it difficult to implement.

[lopi-py]

Seems like trouble first emits an empty buffer (no bufname, no buftype, no filetype) and then changes that, I'm no sure how to improve the enable function given that

In the blue part dropbar recognizes it as a normal buffer

enable = function(bufnr, winnr)
  print(vim.api.nvim_buf_get_name(bufnr), vim.bo[bufnr].filetype, vim.bo[bufnr].buftype, "|")
  return true -- testing
end

[Bekaboo]

@lopi-py How about letting enable() return false if &ft/&bt/bufname is empty?

[lopi-py]

enable = function(bufnr, winnr)
  -- default enable function
  return not vim.api.nvim_win_get_config(winnr).zindex
    and vim.bo[bufnr].buftype == ""
    and vim.bo[bufnr].filetype ~= "" -- new check
    and vim.api.nvim_buf_get_name(bufnr) ~= ""
    and not vim.wo[winnr].diff
end

Yeah, checking if the filetype is not empty seems to work, thanks @Bekaboo

[lopi-py]

Reopening since now a file without extension won't get the dropbar (which I like because I can click it and switch to other file, ignore the tab view, it's not neovim)

[Bekaboo]

Can you try detecting the bufname in the enable() function instead and return false if it is empty or contains xxxTrouble, etc. ?

[lopi-py]

@Bekaboo sorry for the later response, this seems to work

enable = function(bufnr, winnr)
  local path = vim.fs.normalize(vim.api.nvim_buf_get_name(bufnr))
  if vim.bo[bufnr].buftype ~= "" or path == "" then
    return false
  end
  if path:match "Trouble$" then
    print "trouble skipped"
    return false
  end
  return not vim.wo[winnr].diff
end

but it is some hacky. I think this is related because it sets bufhidden first so dropbar is reached by OptionSet, here is my question, why try to attach the dropbar on every OptionSet?, may it be worth to listen to OptionSet for specific options? something like this

vim.api.nvim_create_autocmd("OptionSet", {
  pattern = "buftype,filetype,diff",
  callback = function(event)
    attach(event.buf, 0)
  end
})

It works fine for me even with the default general.enable

[Bekaboo]

why try to attach the dropbar on every OptionSet?, may it be worth to listen to OptionSet for specific options? something like this

vim.api.nvim_create_autocmd("OptionSet", {
  pattern = "buftype,filetype,diff",
  callback = function(event)
    attach(event.buf, 0)
  end
})

It works fine for me even with the default general.enable

Because some will want to attach dropbar when some specific options is set so only listen to &buftype, &filetype, and &diff will be a breaking change.

[lopi-py]

What if it was configurable?

require("dropbar").setup {
  general = {
    -- string | nil
    enable_pattern = nil, -- "buftype,filetype,diff"
  },
}

[Bekaboo]

What if it was configurable?

Good idea, will think about this later