Closed lopi-py closed 1 year ago
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.
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
@lopi-py How about letting enable()
return false
if &ft
/&bt
/bufname is empty?
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
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)
Can you try detecting the bufname in the enable()
function instead and return false
if it is empty or contains xxxTrouble
, etc. ?
@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
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.
What if it was configurable?
require("dropbar").setup {
general = {
-- string | nil
enable_pattern = nil, -- "buftype,filetype,diff"
},
}
What if it was configurable?
Good idea, will think about this later
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 falseExpected behavior
The dropbar should be detached (if attached first) from the given buffer if
general.enable
returns false