[vim/vim] `:bdelete` does not close a window if there is no listed buffers (Issue #19389)

6 views
Skip to first unread message

Evgeni Chasnovski

unread,
Feb 12, 2026, 1:22:54 PM (2 days ago) Feb 12
to vim/vim, Subscribed
echasnovski created an issue (vim/vim#19389)

Steps to reproduce

  1. Create 'init-bdelete-close.vim' with the following content:

    enew
    setlocal nobuflisted buftype=nofile
    
    vert split
    enew
    setlocal nobuflisted buftype=nofile
  2. vim --clean -u init-bdelete-close.vim

  3. Execute :ls! to see that there is only two scratch buffers, both unlisted.

  4. Execute :bdelete. The window is not closed and instead the same buffer (judging by the buffer number after :ls!) is made listed.

If 'init-bdelete-close.vim' is prepended with edit temp, then step 3 :ls! will show two unlisted scratch and one listed buffer (that is not visible). Then :bdelete from step 4 closes the window, although the listed buffer is never shown.

Expected behaviour

:bdelete behavior regarding closing windows does not depend on whether there is a not shown listed buffer. From the :h :bdelete:

Any windows for this buffer are closed.
If buffer [N] is the current buffer, another buffer will be displayed instead.
This is the most recent entry in the jump list that points into a loaded buffer.

Both buffers have an entry in the jumplist prior to :bdelete (verified by :echo getjumplist()), so I would say that the current behavior is both not expected and not according to documentation (the "Any windows for this buffer are closed" part).

Version of Vim

9.1.2132

Environment

OS: EndeavourOS Linux x86_64, 6.18.7-arch1-1
Terminal: Ghostty 1.2.3-arch2
$TERM: xterm-ghostty
Shell: Nushell 0.110.0

Logs and stack traces


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19389@github.com>

Christian Brabandt

unread,
Feb 13, 2026, 9:41:16 PM (yesterday) Feb 13
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#19389)

Check the :ls! output closely:
Before the :bd it looks like this:

:ls!
  1u#a   "[Scratch]"                    line 1
  2u%a   "[Scratch]"                    line 1

After executing the :bd it looks like this:

:ls!
  1u#a   "[Scratch]"                    line 1
  2 %a   "[No Name]"                    line 1

Note that buffer 2 is now named [No Name].

I think what is happening is that the buffer is deleted and a new buffer is created, but it re-uses the old buffer structure (`:h buffer-reuse) which is then displayed and no longer unlisted.

Vim does however not close the window, if there are no listed buffers (or is trying to delete the last listed window). I believe this is to ensure that the window structure will always be valid and contain a valid buffer.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19389/3899346369@github.com>

Evgeni Chasnovski

unread,
Feb 13, 2026, 9:52:59 PM (yesterday) Feb 13
to vim/vim, Subscribed
echasnovski left a comment (vim/vim#19389)

Note that buffer 2 is now named [No Name].

In both cases the buffer name is empty string. The difference is that before it was unlisted, but listed after.

I think what is happening is that the buffer is deleted and a new buffer is created, but it re-uses the old buffer structure (`:h buffer-reuse) which is then displayed and no longer unlisted.

Yes, this might indeed be the case.

Vim does however not close the window, if there are no listed buffers (or is trying to delete the last listed window). I believe this is to ensure that the window structure will always be valid and contain a valid buffer.

Not listed buffer is still a valid buffer. It is and can be shown in multiple windows.

What feels wrong is that the behavior of whether to close the window depends on something that is not shown before and is not meant to be shown after, i.e. a loos listed buffer. I'd expect that the window is closed in both mentioned cases, as it seems to follow the documentation (and common reason).


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19389/3899397463@github.com>

Christian Brabandt

unread,
Feb 13, 2026, 9:56:56 PM (yesterday) Feb 13
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#19389)

There is this remark in the code:

        // If deleting the last (listed) buffer, make it empty.
          // The last (listed) buffer cannot be unloaded.
          FOR_ALL_BUFFERS(bp)
              if (bp->b_p_bl && bp != buf)
                  break;
          if (bp == NULL && buf == curbuf)
              return empty_curbuf(TRUE, (flags & DOBUF_FORCEIT), action);

This also applies to the situation when there are no listed buffers. It will just empty the current buffer and not close the window. I'll update the help a bit


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19389/3899413440@github.com>

Christian Brabandt

unread,
Feb 13, 2026, 9:57:35 PM (yesterday) Feb 13
to vim/vim, Subscribed

Closed #19389 as completed via 48cee53.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/19389/issue_event/22777930541@github.com>

Justin M. Keyes

unread,
2:30 PM (9 hours ago) 2:30 PM
to vim/vim, Subscribed
justinmk left a comment (vim/vim#19389)

What feels wrong is that the behavior of whether to close the window depends on something that is not shown before and is not meant to be shown after,

Doesn't this mean :bdelete has essentially random behavior? scratch buffers can exist for any random reason.

Is there a best practice that plugin authors should follow, to avoid this?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19389/3901920882@github.com>

Reply all
Reply to author
Forward
0 new messages