Create 'init-bdelete-close.vim' with the following content:
enew setlocal nobuflisted buftype=nofile vert split enew setlocal nobuflisted buftype=nofile
vim --clean -u init-bdelete-close.vim
Execute :ls! to see that there is only two scratch buffers, both unlisted.
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.
: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).
9.1.2132
OS: EndeavourOS Linux x86_64, 6.18.7-arch1-1
Terminal: Ghostty 1.2.3-arch2
$TERM: xterm-ghostty
Shell: Nushell 0.110.0
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
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.![]()
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.![]()
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.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
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.![]()