[BUG]: winbar shows in terminal buffers in some cases

[cdelledonne]

Requirements

• [X] I have skimmed other issues to see if this bug has already been reported.
• [X] I'm fully certain that this is not a breaking change, see the latest release.
• [X] This plugin and its dependencies are up to date with the latest commit.
• [ ] I'm willing to fix this through a PR.

Expected Behavior

If I just start a terminal by for instance running :call termopen(['ls'], {}), there is no winbar in the current window (the current window is occupied by the terminal buffer). This is the behavior that I expect from barbecue.

Now, I would also expect this behavior to be the same when doing the following set of actions

• Open a new window
• Create a new buffer
• Start a terminal in this new window
• Go back to the previous window

This is expressed by this function:

function TestBarbecue() abort
    let l:orig_winid = bufwinid('%')
    vsplit
    enew
    call termopen(['ls'], {})
    call win_gotoid(l:orig_winid)
endfunction

Actual Behavior

When calling the function defined above as :call TestBarbecue(), what I get is that there is a winbar in the window occupied by the terminal buffer. This is not expected (nor wanted, in my use case).

Removing the line call win_gotoid(l:orig_winid) restores the expected behavior, i.e. no winbar in the terminal window. Interestingly, keeping the line call win_gotoid(l:orig_winid) but adding a sleep 1m just before the call to termopen() also restores the expected behavior.

Neovim Version

NVIM v0.9.2
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -fno-common -Wno-unused-result -Wimplicit-fallthrough -fdiagnostics-color=auto -fstack-protector-strong -DUNIT_TESTING -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/usr/include/luajit-2.1 -I/usr/include -I/usr/include/luv -I/builddir/build/BUILD/neovim-0.9.2/redhat-linux-build/src/nvim/auto -I/builddir/build/BUILD/neovim-0.9.2/redhat-linux-build/include -I/builddir/build/BUILD/neovim-0.9.2/redhat-linux-build/cmake.config -I/builddir/build/BUILD/neovim-0.9.2/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Minimal Configuration

Simple init.vim to reproduce the issue:

call plug#begin('~/.local/share/nvim/plug')
Plug 'SmiteshP/nvim-navic'
Plug 'utilyre/barbecue.nvim'
call plug#end()
lua require('barbecue').setup()

Reproduction

1. Define the function TestBarbecue() as specified in Expected Behavior
2. Run the function as :call TestBarbecue()
3. Observe that the window with the terminal buffer has a winbar

[cdelledonne]

Possibly related to #92 and #34

[cdelledonne]

I've done some more digging, here's what I concluded:

By default, an update to the winbar is only performed on the events WinResized, BufWinEnter, CursorMoved, InsertLeave, as defined by barbecue. However, opening a terminal with e.g. termopen() does not trigger any of the above events. Nevertheless, when running the command passed to termopen(), some lines are appended to the terminal buffer, and this triggers CursorMoved as a side effect (or so it seems). This event is actually triggered two times when launching termopen() directly, but only one time when launching it as part of the function TestBarbecue() defined in the original description of this issue. This discrepancy seems to be enough for the unexpected behavior described above.

Given that, I would think that there should be an additional event that should perform a winbar update, and this event should be triggered when launching a terminal. More in general, there should be an event that's triggered whenever buftype changes for the current buffer, but as far as I know this only happens when launching a terminal.

Based on this assumption, I tried adding TermOpen to the list of events that perform a winbar update, but this does not solve the problem. The function update() in lua/barbecue/ui.lua does not seem to have the logic to disable the winbar for a buffer whose buftype has just changed.

Does this make sense?