repeatedly bufferizing the same command results in window- and buffer-destructive behaviour

[pkfm]

do the following:

• let g:bufferize_keep_buffers = 0
• :Bufferize messages
• observe expected output i.e. captured command output presented in a new window split
• :Bufferize messages
• observe no visual changes or the next observe list item
• :echo nonexistentvar
• :Bufferize messages
• observe Bufferize either
  • 'overlay' the content with captured output making it impossible to return to the origin buffer without closing the window and re-opening the buffer
  • replace the contents of the buffer making it impossible to keep changes unsaved before running a bufferized command, in addition to making return to the origin buffer difficult

i've observed no difference with different values of g:bufferize_keep_buffers. i've also observed this behavior on vim 8.1, vim 8.2, nvim 0.4.3, and nvim 0.5.0-699-gd4b4335fe with the latest bufferize.vim version from this repo and a minimal vimrc consisting of nothing but a (vim)plug command for this plugin, though the behavior varies slightly between vim and nvim.

[AndrewRadev]

I couldn't replicate the issue with Bufferize messages, but I could easily find a problem with BufferizeTimer 100 messages. I recently added some logic that checks for changes and short-circuits, and I'd forgotten to restore state properly in that case.

I've pushed a possible fix. Could you try it again and let me know how it goes? If you're still having a problem, I'll experiment with a minimal vimrc and see if I can get the same results.

[pkfm]

so i tested the update and i'm still experiencing problems.

i insert some filler text or open a file to provide some visual feedback and then execute :messages. in vim i observe a window split with this message:

Messages maintainer: Bram Moolenaar <[email protected]>

ls! output is

1 %a  "[No Name]"             line 1
2  a  "Bufferize: messages"   line 0

as long as i leave the split open, successive bufferize calls continue to appear in the new buffer within the newly created split. once the buffer is deleted and becomes unlisted the behavior gets hairy. ls! output is then

1 %a  "[No Name]"             line 1
2w    "Bufferize: messages"   line 1

upon executing once more, bufferize messages, the output is put into buffer 1. the action can be undone as long as i don't change buffers. if i go to buffer 2 and then back to buffer 1, the bufferized messages are lost (expected with let g:bufferize_keep_buffers = 0) along with the contents of buffer 1 (unexpected) and the undo history. attempt to undo the change claims i'm already at the oldest change.

the experience is similar in nvim except that the current buffer's contents are not overwritten until the bufferized command's output changes from the last invocation. bufferizing the command makes no visible changes until the output is altered. when the command output changes once, the behavior follows that of vim with every call thereafter.

if i let g:bufferize_keep_buffers = 1 and only :close bufferized buffers and never :bdelete them, then the plugin behaves as expected, but then there is, as you say, some garbage about. though this option does seem useful, especially in combination with BufferizeTimer.

for convenience here are the minimal .vimrc i used:

call plug#begin('~/.vim/plugs')
Plug 'AndrewRadev/bufferize.vim'
call plug#end()

and here is the minimal init.vim i used:

set runtimepath^=~/.vim
let &packpath = &runtimepath
source ~/.vimrc

absolutely minimal as you can see. hopefully this is helpful.

[AndrewRadev]

I've managed to replicate the issue. I think the problem is I set bufhidden=delete, which doesn't remove the buffer from the buffer list, so it exists, and is not hidden, but it's also not loaded. Honestly, to this day I still can't remember which option did what. The help files are uncharacteristically unhelpful too, saying "Don't use this unless you know what you are doing".

Anyway, I've pushed a commit to master that should fix this. Let me know if it works, but also keep an eye out for any new issues with it, just in case.