<Leader>bs shows the wrong buffer… sometimes

[mscheper]

I've been using and loving Bufexplorer for well over 15 years, but in recent months, it's sometimes opened a buffer other than the one I selected. This happens maybe once or twice a week, and I've always just quit gVim and started a new session to work around it.

I haven't filed an issue before now, because, unfortunately, I don't have a reliable set of steps for making it happen. But I can reproduce the issue in my gVim session right now. I'm hoping that, if I tell you about my setup and what's changed, you could suggest things to try, to see whether I can reproduce it more reliably.

I started this gVim session a few hours ago, using a Bash script that loads 26 files. Honestly, I wrote the script because of this bug; I always made heavy use of :mksessions, but having a clean starting point of frequently needed files for this project has been pretty useful, too. Anyhow, I've been using Bufexplorer and other tools during this session without issue, until now. Now, when I type \bs (\ being my Leader), I see 27 buffers, the highest number being 33, because I've loaded a few other files and deleted them (d) in Bufexplorer. That's all good, except that, consistently, when I move the cursor to buffer 33, a file called 'home.html', and type Enter, it instead loads buffer 4, one of the 'urls.py' files that I've also been editing.

When I first noticed this issue today, I had my session split into four windows, and I was trying to use \bs to open a fifth. I closed most of the windows with :q, and used \be to load various other files, all of which loaded correctly. Still, when I try to load the file I want, 'home.html', it loads that 'urls.py' instead. Strangely, 'home.html' is listed with the %a attributes, but I'm pretty sure I never actually had it open. The relevant 'urls.py' is also listed as active, i.e. with a.

One thing I did that might have confused Bufexplorer this time is that previously, for 'home.html', file, I used :file and :w to create a copy of the file under a new name. I've had this issue come up without me having done that, though, so this may be a red herring. I've also done this many times over the years without Bufexplorer acting up, but maybe this is a new bug, or something related to a newly installed plug-in.

When I've previously noticed this issue, once or twice I found that the buffer I wanted was actually being loaded into another tab. I've never used tabs in gVim, so it may have happened more often than that without me noticing. There are no tabs visible now, though. I recently disabled the menu bar in my .vimrc, but even when I make it appear again now, with set guioptions+=m, still no tabs appear.

I'm using bufexplorer 7.5.0 (so #117, which seemed vaguely related, should be fixed?) under gVim 9.1. I was also experiencing this issue under gVim 8.2. My OS is Linux Mint 21.3 Cinnamon.

These are the other plug-ins I have installed:

Plug 'editorconfig/editorconfig-vim'
Plug 'jlanzarotta/bufexplorer'
Plug 'tmhedberg/SimpylFold'
Plug 'vim-scripts/indentpython.vim'
Plug 'Rigellute/shades-of-purple.vim'
Plug 'Valloric/YouCompleteMe'
Plug 'dense-analysis/ale'
Plug 'nvie/vim-flake8'
Plug 'sbdchd/neoformat'
Plug 'tpope/vim-surround'
Plug 'mtdl9/vim-log-highlighting'
Plug 'stevearc/vim-arduino'
Plug 'tpope/vim-abolish'
Plug 'chrisbra/csv.vim'
Plug 'madox2/vim-ai'

I've installed the bottom three pretty recently, but after I started noticing this issue. I've used most of the rest since well before I started noticing this issue. However, I've made a lot of changes to my ALE setup (dense-analysis/ale) and YouCompleteMe in recent months. I honestly can't remember whether this issue started happening before I started making those changes, and since this issue occurs fairly seldomly, even if I revert those changes today, it'd take a week or two of this issue not occurring, to convince myself that they're related. And then it would open the whole can of worms for which changes are causing the problem.

But if you can think of things to try that might reproduce the issue more quickly, I could give it a go and let you know.

Sorry this is so vague.

[drmikehenry]

I'm sorry to hear about this frustrating intermittent problem.

You mention running 7.5.0 now, where you are seeing the problem. Do you have an idea which version of BufExplorer you were using in the past before you first encountered this issue? You might be able to narrow things down by running that older version of BufExplorer for a while to verify that the issue doesn't occur, rather than trying to revert your ALE and YouCompleteMe changes. There still could be some interaction between the plugins, but having a smaller range of BufExplorer versions to consider would be helpful.

Visiting the wrong buffer when pressing <Enter> is a surprising behavior. BufExplorer's s:SelectBuffer() function chooses a buffer to open:

bufexplorer/plugin/bufexplorer.vim

Line 802 in 13a64f2

function! s:SelectBuffer(...)

When pressing <Enter>, the buffer number is determined on line 831 via:

let _bufNbr = str2nr(getline('.'))

The current line in the BufExplorer window is retrieved and converted to a number. Vim's str2nr() function will skip over leading spaces, convert any digits it finds, and stop at the first non-digit in the string, e.g.:

:echo str2nr(' 33u      home.html  /path/....')

In the usual case, the flow picks up with line 882. In your scenario with only a single tab open and with home.html not open in any existing windows when you place your cursor on home.html and press <Enter>, tabNbr should be zero (since home.html would not be found in a window in any tab). In that case, line 889 should result in executing keepjumps keepalt silent b!33 for your example. Even if you have more tabs open and home.html were open in another tab, the expected behavior (when "Locate buffer" is enabled) is to switch to that tab and window where home.html is already open. So I don't immediately see how the wrong buffer could be selected, assuming your cursor is indeed on the home.html line in the BufExplorer window when you press <Enter>.

One way to verify how may tabs are open is to echo the last tab number (which is also the number of open tabs):

:echo tabpagenr('$')

But I'm assuming you indeed had only the one tab open during your tests.

For the case of opening into another tab, I wonder whether you might have pressed shift-<Enter> instead of just <Enter>. Shift-<Enter> is an alias for t, which opens the buffer in a new tab.

When you next encounter the issue, it might help to ensure you have only one tab open, then close all but one window and use \be to launch BufExplorer. That would narrow the logic in s:SelectBuffer(). If you are trying to open buffer 33 (for example) but are ending up elsewhere, maybe you could exit BufExplorer via q and then manually try to switch to the buffer via keepjumps keepalt silent b!33 (as BufExplorer does). I'd expect that to work; if it does, then perhaps switch back to another buffer, launch via \be and try again.

[mscheper]

@drmikehenry: I appreciate your thoughtful reply.

My best guess for which version of Bufexplorer I was using, before I first noticed this issue, would be either 7.4.23 or 7.4.26. (I started working on a new project early-to-mid 2023, using tech I hadn't used in a while, and that's when I usually update my tools and scripts.) Looking at the release notes since then, and from your description of s:SelectBuffer(), it's indeed hard to see what could be causing this issue. But next time it happens, I'll come back to your comment, and see if I can get more information.

OTOH, it's quite conceivable that I accidentally pressed Shift+Enter at some point, given that the right Shift key sits right below Enter on my keyboard. I might even be able to blame the cat for that. 🙀 Thanks for that insight.

BTW, can you please tell me how you link to a line of code in a GitHub comment like that? I often want to do it but have never found a way, and your comment is somehow the first where I've seen it done.

[drmikehenry]

One idea for getting a little more information is to use the below script to watch Vim's autocommands.

Save this script as bufx.vim:

function! Bufx_log(msg)
    call writefile([a:msg], '/tmp/bufx.log', 'a')
endfunction


function! Bufx_record(cmd)
    let bufNbr = expand('<abuf>')
    let winNbr = winnr()
    let tabNbr = tabpagenr()
    let name = expand('<afile>')
    let numWindows = winnr('$')
    call Bufx_log(printf('%-12s %3s, %3s, %3s, #win=%2d, «%s»',
            \ a:cmd, bufNbr, winNbr, tabNbr, numWindows, name))
endfunction


augroup Bufx
    autocmd!
    autocmd BufNew * call Bufx_record('BufNew')
    autocmd BufEnter * call Bufx_record('BufEnter')
    autocmd BufDelete * call Bufx_record('BufDelete')
    autocmd BufWipeout * call Bufx_record('BufWipeout')
    autocmd WinEnter * call Bufx_record('WinEnter')
    autocmd WinLeave * call Bufx_log('') | call Bufx_record('WinLeave')
    autocmd TabNew * call Bufx_record('TabNew')
    autocmd TabEnter * call Bufx_record('TabEnter')
    autocmd TabLeave * call Bufx_record('TabLeave')
    autocmd TabClosed * call Bufx_record('TabClosed')
augroup END

This script may be sourced at any time in a running Vim instance via:

:source bufx.vim

It creates a log file recording the comings and goings of buffers, windows, and tabs. The columns in the log file are:

Event  bufferNumber  windowNumber  tabNumber numberOfWindows  filename

It's got a hard-coded path to the log file (/tmp/bufx.log at present); tailor this path as you see fit.

After sourcing, below is the output from launching BufExplorer via \be and choosing file1.txt which is loaded into buffer 1:

BufNew       152,   1,   1, #win= 1, «[BufExplorer]»
BufEnter     152,   1,   1, #win= 1, «[BufExplorer]»
BufDelete    152,   1,   1, #win= 1, «[BufExplorer]»
BufWipeout   152,   1,   1, #win= 1, «[BufExplorer]»
BufEnter       1,   1,   1, #win= 1, «file1.txt»

When you next encounter the issue, you can source this script and then watch the log file as you trigger the issue. If there's some weird interaction with other plugins, perhaps you'll be able to see something interesting in the logs (e.g., a BufEnter for your actual desired file followed by another BufEnter of the wrong file).

You could also patch the Bufx_log() function into BufExplorer itself such that you could add tracing to the logic in BufExplorer to show what's going on (perhaps logging the chosen buffer number in s:SelectBuffer() or something).

I endorse the time-honored approach of blaming the cat! :-)

Github has a "permalink" feature for linking into code. To make a permalink:

• Visit the repository: https://github.com/jlanzarotta/bufexplorer

• Visit a file of interest: https://github.com/jlanzarotta/bufexplorer/blob/master/README.md

• Choose the "Code" tab showing line numbers and the raw text (necessary for file types such as Markdown that have a "Preview" feature).

• Click on a line number of interest (say, line 5); triple dots will appear beside the line number.

• Click on the triple dots and choose "Copy permalink":

  bufexplorer/README.md

  Line 5 in 93ad8af

  BufExplorer Plugin for Vim

You can optionally choose a different branch or tag before navigating to the file and line number.

Only after typing the above did I think to hunt up a reference: https://github.com/github/docs/blob/main/content/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet.md