Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tabline sometimes disappears when closing location list #39

Closed
deathlyfrantic opened this issue Nov 16, 2017 · 5 comments
Closed

Tabline sometimes disappears when closing location list #39

deathlyfrantic opened this issue Nov 16, 2017 · 5 comments

Comments

@deathlyfrantic
Copy link
Contributor

This is a really peculiar bug that only happens sometimes, and I'm not even sure buftabline is the responsible party. I have an autocmd set up to run Neomake on every BufWritePost. If there are errors, they get populated into the location list. If I correct the errors, save again, and Neomake finds no errors remaining, it will close the location list, which somehow makes the tabline disappear. Here's a terrible quality gif to demonstrate:

bug

This is on Neovim 0.2.1 FWIW. I've tried all manner of ways to reproduce this and have yet to track down the root cause. I have been able to reproduce it without using Neomake (just by using laddfile somefile.txt, lopen and lclose). I've looked through buftabline's source and nothing has jumped out at me as being an obvious culprit, but I can't claim to fully understand everything it does. Mostly I'm just reporting it here as a first step, to see if you have any thoughts.

@deathlyfrantic deathlyfrantic changed the title Tabline sometimes disappears when closing quickfix list Tabline sometimes disappears when closing location list Nov 16, 2017
@ap
Copy link
Owner

ap commented Nov 17, 2017

At the point where you :call buftabline#update(0), can you :set tabline? showtabline? instead, and post its output?

@deathlyfrantic
Copy link
Contributor Author

deathlyfrantic commented Nov 17, 2017

tabline=%!buftabline#render()
showtabline=1

And FWIW, my buftabline settings:

let g:buftabline_show = 1
let g:buftabline_indicators = 1
let g:buftabline_numbers = 2

I've finally nailed down a reliable way to reproduce this. Use this file (which I called min.vim) and adjust as necessary:

set hidden
let g:buftabline_show = 1
let g:buftabline_indicators = 1
let g:buftabline_numbers = 2
source $HOME/.config/nvim/plugged/vim-buftabline/plugin/buftabline.vim
e 123.txt
w
e 456.txt
laddfile 123.txt
lopen
wincmd k

Then nvim -u NONE -c "source min.vim". Your cursor should end up in the 456.txt buffer, and if you :lclose, the tabline should disappear along with the location list. Happens to me every time.

EDIT: Also appears to happen with regular Vim version 8.0.642.

@ap ap added the bug label Nov 17, 2017
@ap
Copy link
Owner

ap commented Nov 17, 2017

Thank you for the effort! Much appreciated. I’ll take a look as soon as I have some time for it, and having a reliable reproduction makes that time a lot more likely to yield a fix.

deathlyfrantic added a commit to deathlyfrantic/vim-buftabline that referenced this issue Nov 17, 2017
This should fix ap#39 - `lclose` can sometimes cause the tabline to
disappear even when there are multiple buffers remaining. Essentially
the problem is buftabline always assumes the buffer being deleted is the
current buffer, which is generally true, but not always true.

`bufnr('%')` gives us the number of the _current_ buffer which is not
necessarily the buffer that is being added or deleted. `expand(<abuf>)`
gives us the number of buffer on which the event is operating, but as a
string - so we need to convert it to a number with `str2nr`. We can then
determine if the actual buffer being deleted is a user buffer or not.
@deathlyfrantic
Copy link
Contributor Author

I finally figured this out! See #40. I don't think that change should break anything else, and it resolves this issue.

@ap
Copy link
Owner

ap commented Nov 17, 2017

Well thank you for doing all of the work. 😊

@ap ap closed this as completed in e662ccd Nov 17, 2017
@ap ap added the resolved label Jan 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants