UpdateLastColumn failed to find bufnr with vim-plug

Question

UpdateLastColumn failed to find bufnr with vim-plug

Closed this issue 5 years ago · 23 comments

When closing vim-plug's :PlugUpdate window/buffer with q, I'm getting:

Thoughts or advice?

Answer 1 · 2018-11-21T12:01:13.000Z

I don't use vim-plug, but I downloaded it, set up the config, ran PlugInstall, and it tried to work. It failed to download successfully, but it was running at least. Closing that window worked fine for me.I then tried PlugUpdate - which failed in the same way - but closing the window with :q worked, and generated no errors for me from bufkill. Obviously it's much easier to debug an error when you can see it.In general though, yes, I've seen that error pop up intermittently before, but it's never been consistent enough for me to fix.So I'm sorry, I don't really think I can help...

Answer 2 · 2018-11-21T12:43:19.000Z

Hmm, thank you for trying, I appreciate you downloading vim-plug in order to try it. What's weird to me is, this never used to happen. It has only started happening with vim-plug and vim-bufkill very recently 🤔

Answer 3 · 2018-11-21T21:12:34.000Z

Curious. Obviously bufkill hasn't changed in a while, so the obvious question is whether vim-plug has - and yet if it were a change to vim-plug (like, perhaps, a change to create their buffer as a scratch buffer or something - which somehow avoids firing the BufAdd event), I should have got the new code and seen the same issue. If you can produce it reliably however, maybe we could get something if you turn on the bufkill debug logging.Before you run PlugUpdate, set my debug level thus :let g:Debug=5 Before you run PlugUpdate, it would be good to see a list of your buffers. Hopefully you can get that list into your clipboard with :redir @*|buffers|redir END to paste it in here. Then run PlugUpdate, and you'll see a bunch of debug stuff - just hit enter when it's done - and then close the window as usual, and you'll get a bunch more stuff, again, hit enter. Then to copy all that into your clipboard, use :redir @*|mess|redir END and paste it all in here. Without being about to recreate the error myself it may still be too difficult, but it might help, at least. Then you can reset the debug variable :unlet g:Debug and also clear the CursorHold debug event with :autocmd! CursorHold

Answer 4 · 2020-02-03T01:27:01.000Z

@qpkorr I can give you another case to test this error, I'm using nvim and trying to make vim-plug to open in a floating window instead of a side panel. You can paste this in the init.vim file:

function! FloatingPlug()
 " Style of the floating window
  let height = &lines - 3
  let width = float2nr(&columns - (&columns * 2 / 10))
  let col = float2nr((&columns - width) / 2)
  let opts = {
        \ 'relative': 'editor',
        \ 'row': height * 0.3,
        \ 'col': col,
        \ 'width': width * 2 / 2,
        \ 'height': height / 2
        \ }

  let buf = nvim_create_buf(v:false, v:true)
  let win = nvim_open_win(buf, v:true, opts)
  " Set Floating Window Highlighting
  call setwinvar(win, '&winhl', 'NormalFloat:TabLine')

  " this is to remove all line numbers and so on from the window
  setlocal
        \ buftype=nofile
        \ nobuflisted
        \ modifiable
        \ bufhidden=hide
        \ nonumber
        \ norelativenumber
        \ signcolumn=no
endfunction
let g:plug_window = 'call FloatingPlug()'

Every time you run :PlugInstall a new floating window will open in the middle of the screen and if you press q to close it, then you'll get the error described at the beginning.

Answer 5 · 2020-02-03T02:02:10.000Z

I can second the floating window case. I hit that the other day and haven’t had the time to find a minimal repro yet. Thanks for posting one!

Answer 6 · 2020-02-06T17:05:36.000Z

i also have the same problem when i do :Files from fzf_vim and press escape or Ctrl-C

Answer 7 · 2020-02-06T17:06:29.000Z

i dont get why bufkill is even being called... i disabled all mapping i only use :BD sometimes

Answer 8 · 2020-02-07T00:13:13.000Z

@dagadbm in order for :BD to work when you do use it, it has to track every time you open, close, or change buffer in a window, so it can have an up to date list of your most recent buffer usage, to know which buffer to display when you close one. So it acts upon a number of buffer events.

Thanks for the minimal error cases, this problem has been there a long time, it would be nice to finally fix it - though I've got a new baby, and am currently organizing a memorial for a close family member's recent death - so don't hold your breath. I'd always hoped that base vim would get this functionality built in so my little plugin could go the way of the dodo years ago... but seemingly that hasn't yet happened, alas.

Answer 9 · 2020-02-18T07:32:39.000Z

@qpkorr don't worry, your plugin is still really useful. Take your time and hopefully, in the future you'll have more time to spent looking at this or maybe knows how to give a check and try to get a fix with all the information here.

Answer 10 · 2020-04-26T19:20:49.000Z

I just wanted to say that I use this plugin A LOT, :BP, :BB and :BD are precious gems for me. Well done 👏 and thank you 😄

Regarding this bug, it also happens for me when using fzf in a floating window in neovim and I think I know the problem.

In the above scenario, the buffer name (bufname('%')) is empty so we can't find the index to save in the list inside the <SID>UpdateLastColumn(event) function.

I fixed that by adding this check to this function:

function! <SID>UpdateLastColumn(event) "{{{1
  " Function to save the current column and buffer and window numbers,
  let DebugF = 'UpdateColumnList'
  call s:Debug(1, DebugF, 'Entering(' . a:event . '): win = ' . winnr() . ', buf = ' . bufnr('%') . ' (' . bufname('%') . ')')
  call s:Debug(2, DebugF, 'w:BufKillList')
  call s:Debug(2, DebugF, 'w:BufKillColumnList')
  call s:Debug(2, DebugF, 'w:BufKillIndex')
  if !bufname('%') " <<<<<<<<<<<<<<<<<<<< THIS CHECK HERE <<<<<<<<<<<<<<<<<<<
    call s:Debug(1, DebugF, 'Buffer name is empty, nothing to do here')
    return
  endif
  if !exists('w:BufKillList')
    " Just give up for now.
    return
  endif
  let index = index(w:BufKillList, bufnr('%'))
  if index != -1
    " Extend list if required, then set the value
    let w:BufKillColumnList += repeat([0], index - len(w:BufKillColumnList) + 1)
    let w:BufKillColumnList[index] = col('.')
  else
    echom 'UpdateLastColumn failed to find bufnr ' . bufnr('%') . ' in w:BufKillList'
  endif
  call s:Debug(2, DebugF, 'w:BufKillList')
  call s:Debug(2, DebugF, 'w:BufKillColumnList')
  call s:Debug(2, DebugF, 'w:BufKillIndex')
  call s:Debug(1, DebugF, 'Exiting (' . a:event . ')')
  " redraw  " To hide call Debug messages for now!
endfunction

I'm going to open a PR to add that is that's ok 👍 🎉

Answer 11 · 2020-04-26T19:32:43.000Z

thanks for investigating this issue, just to add, I see a few error messages in the status bar if I spawn a floating window for fzf and terminal window or tmux pane is too small. Not sure if is related to this issue or a different thing.

Thanks for the PR, will try and confirm if it solves the problem in different scenarios. 👍

Answer 12 · 2020-04-26T19:42:37.000Z

Awesome, thanks @Gioyik .

This bug also happens when running :tabnew for me. I just opened the PR =)

Answer 13 · 2020-04-26T23:59:02.000Z

Hi @lucasprag - thanks so much! I still feel like it's ridiculously complex code for what it's trying to achieve, and I'm super impressed when anyone else manages to understand it.

My only curiousity - without yet having had time to check out the code myself - is whether bufname being empty should be such a problem. The plugin works (should work...?) mainly with bufnums - the same bufnum can be opened in multiple windows, but can one open the same file with two different bufnums? I thought not. Hence - is the problem that bufname is empty - or that we have a new bufnum that hasn't yet been added to w:BuffKillList, but should have been? Or should these 'anonymous buffers' be rightly excluded from this buffer handling... it's too long ago for me to recall.

Either way your change is clearly an improvement :) - but do you think there's more to do?

Answer 14 · 2020-04-27T03:10:13.000Z

Awesome, thanks =) Like I said, it's a great plugin and I use it everyday, great work 👍

Interesting, I'm trying to understand it further. It doesn't seem to happen on :tabnew like I said, but notice the different between :tabnew and opening a new floating window (in my case using fzf.vim like :Files)

:tabnew

floating window

Answer 15 · 2020-04-27T03:15:40.000Z

Now with level 2 debugging enabled:

tabnew

floating window

Not sure if this helps, but notice that for the floating window, no buffer events are triggered. BufEnter, BufAdd nor BufLeave. It should be ok since we have the same functions mapped to the window events like WinEnter and WinLeave.

Anyway, I'm still trying to understand what happens with floating windows =)

Answer 16 · 2020-04-27T13:34:24.000Z

Glad you like the plugin and thanks - though it still disappoints me that it's not the standard, built in behaviour - like it is in emacs. Anyway - yay for customizability.

Thanks for your observations. That does certainly explain it I suppose (as best I understand it...) - no BufAdd etc means the lists don't get populated, so of course we can't find the buffer in the lists. In which case - the error might be expecting the lists to be populated by all buffers, and thus we should just stop issuing a warning in this scenario, just return. The question of whether we should or shouldn't include this buffer in the lists is moot if we don't know how to :)

One other minor consideration - I just noticed that the description of BufAdd includes the comment: "NOTE: When this autocommand is executed, the current buffer "%" may be different from the buffer being created """
So calling bufnr("%") as I do may not work as expected... hmmm

Answer 17 · 2020-04-27T16:02:49.000Z

Oh this is really interesting, I tried to find a way to populate the list when on WinNew, but it wasn't working and I don't know why even though the event was been called, also no notes on :h WinNew.

I think just returning when index is -1 is good due to floating windows. Is that ok if I update my PR?

Answer 18 · 2020-04-27T16:18:17.000Z

wait, shouldn't the list get populated on WinEnter?

Answer 19 · 2020-04-28T14:30:45.000Z

Actually it make sense to not fail like you said, so I updated my PR and it should just work™ 🎉
Thanks @qpkorr =)

Answer 20 · 2020-04-29T00:54:15.000Z

Thanks @lucasprag. I'm hopeful this is a satisfactory approach - but in case there's more going on here (eg, bufnr('%') isn't set yet on a BufAdd event) and we get bitten in the future, rather that deleting the warning, I'd rather convert it to a debug message. Code updated - fingers crossed - and thanks everyone for your help (and patience!)

Answer 21 · 2020-04-29T14:24:46.000Z

Awesome, I just updated and it works well, not seeing any messages when opening fzf on a floating window, thanks 🎉 👏

Answer 22 · 2020-05-01T03:49:11.000Z

can confirm is not happening to me anymore, everything looks right and clean.

maybe this can close now?

Answer 23 · 2020-05-01T03:56:23.000Z

Thanks @Gioyik, @lucasprag et al.