(mini.bufremove) create modifiable buffer rather than a scratch buffer

[mehalter]

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

When closing the last buffer with bufremove it gives you a scratch buffer rather than just a normal buffer. This means if you modify it and run :confirm q it won't warn before closing. This can be pretty detrimental especially for people who are used to core vim behavior. By just creating a normal buffer without the nofile buffer type we can re-align mini.bufremove with the core vim behavior that people may be accustom to. This also remains un-opinionated because it doesn't set any file types or buffer types.

If you don't want this change, it could be a good idea to have a configuration option that allows users to align themselves with the core vim behavior if they are used to it.

This also would resolve #372 confusion

[echasnovski]

Thanks for taking your time creating this!

I don't really understand what do you mean by "the core vim behavior that people may be accustom to". Could you elaborate, please?

Showing scratch buffer this scenario is and not a normal one in intentional. The core reasoning behind it is to signal user that there is no more "good" buffers available to show.

At the moment I am more inclined to resolve this along the lines of #389: suggest creating own wrapper functions which perform something extra (like changing 'buftype') when there is no "good" buffers left.

[mehalter]

When I say the "core vim behavior", I'm referring to the default behavior of :bdelete. When you close the final buffer with :bdelete it makes a new empty buffer that is modifiable with filetype= and buftype=, not a scratch buffer.

[mehalter]

I definitely understand your reasoning for changing this default behavior, but it might be a good idea to at least provide a configuration option to allow people to replicate an experience similar to the default behavior they may have become used to in their workflow.

[echasnovski]

When I say the "core vim behavior", I'm referring to the default behavior of :bdelete. When you close the final buffer with :bdelete it makes a new empty buffer that is modifiable with filetype= and buftype=, not a scratch buffer.

I see. This is not entirely the case (running :bdelete/:bwipeout in a fresh Neovim instance with single buffer doesn't remove that buffer), but yes it does seem like built-in buffer delete/wipeout results into "normal" buffer (even single scratch buffer is not removed just has 'buftype' changed).

I am still inclined towards recommending writing own wrapper. Hiding this behavior behind an option will result into a lot of change: it should introduce separate opts argument to all four core functions with proper passing that data to where it will be used... plus tests for each one of them... plus documentation. I'll think about it, though.

[mehalter]

Thanks for your consideration. I understand not wanting to add configuration options. But I think if you want to minimize the configuration and additional features, it's probably a good default to follow the behavior that people may have been accustom to.

• People use nofile for controlling their tabline, statusline, winbar
• they also may rely on :confirm q to protect from accidentally losing changes which they aren't protected from in this methodology. Especially if they close a buffer and don't realize that the current one has nomodifiable set

It is particularly strange that because it is a scratch buffer it is still listed so it's sort of a weird in between of looking legitimate but the only difference is it doesn't know if it's been modified or not

[mehalter]

@echasnovski I just came across another super strange side effect of using a scratch buffer. If I put content inside of the buffer and then save it to a file with :w some_file.py it doesn't correctly replace the current buffer with that new file as an actual buffer would, it doesn't trigger filetype changes, or anything. This doesn't seem like it would be a desired behavior

[A-Lamia]

Hi, love your work.
I'll keep this short as @mehalter has already said most of everything, I'm one of those dumb asses that heavily need the "are you sure you want to quit function" i understand from your perspective it's a lot of work but from a UX point of view its a pretty big shock when you fumble your keys and delete all your stuff :)

[echasnovski]

After sleeping on it, I think I'll make a breaking change here as you've suggested. It is not that big of a break and is obviously matters for more than one person.

I'll merge it to my "backlog" branch, polish this up a bit, and then push to main.

[mehalter]

Thank you so much!

[echasnovski]

@mehalter, this is now added to main in 90e3048.

Thanks for caring so much about details!