fix(winbar): don't modify non-heirline winbar for disabled buffers

[mehalter]

Rather than setting disabled buffers to nil it would be better to just leave the winbar untouched if it was not previously set by Heirline. This is much better for buffers that want to handle their own winbar entirely such as neo-tree which can lead to some major flickering.

Let me know what you think or maybe if we want to add a separate option for this case like disable_winbar_cb and ignore_winbar_cb, but I thought that might end up being a bit confusing to the user.

Example flickering:

[rebelot]

that sounds sensible, it should also be tested launching nvim with file arguments

[rebelot]

btw, I realised I encountered this problem with Neo-tree and I used this work around

        disable_winbar_cb = function(args)
            if vim.bo[args.buf].filetype == "neo-tree" then
                return
            end
            return conditions.buffer_matches({
                buftype = { "nofile", "prompt", "help", "quickfix" },
                filetype = { "^git.*", "fugitive", "Trouble", "dashboard" },
            }, args.buf)
        end,

[mehalter]

@rebelot I update my commit to fix that or -> and. Is that all that you think needs to change?

it should also be tested launching nvim with file arguments

Is this being taken care of in that autocmd? Or do I need to add the check somewhere else? Thanks for your help on this!

[rebelot]

Great, that's all. The autocmd should take care of startup, I just wanted to make sure that this PR does not screw up winbars when launching nvim with multiple arguments (usually diff mode, if not taken care of, only the first buffer will have the winbar set due to some autocmd hell)

[mehalter]

@rebelot have you had a chance to test this out with all of the arguments you wanted to? :)

[mehalter]

Hey @rebelot just wanted to do a quick bump on this to see if you've had a chance to test it out?

[mehalter]

Hey @rebelot, I'm sorry to be an annoyance and keep pinging. Is there any chance this is able to get merged yet?

[mehalter]

I have tested this with many different starting arguments and situations (opening multiple files at once, opening several files in splits, etc.) and it doesn't appear to have any issues at all.

[rebelot]

Hi @mehalter , I am very sorry for the delay in getting back to this!

[mehalter]

No worries at all! I appreciate all your work on this project :) no need to apologize for taking some time away, open source maintenance can be taxing!