nvim-treesitter-context
                                
                                 nvim-treesitter-context copied to clipboard
                                
                                    nvim-treesitter-context copied to clipboard
                            
                            
                            
                        fix: context lines insert to new buffer
fix #163
I'm curious, why making these variables buffer-local solves the issue you linked? Could we solve this by making our buffers scratch-buffers instead?
I can't even produce #163 and have never experienced the issue, which indicates to me there is another problem.
@lewis6991 This issue is random. I think it maybe caused by <C-c> keyboard interrupt and some other plugins interrupt the nvim-treesitter-context running functions.
What I'm sure is that the issue will insert context lines into new buffers (created by nvim_create_buf) or other buffers (like opened neo-tree buffer, the inserted lines will trigger neo-tree to create files).
The function get_bufs will call nvim_create_buf when not context_bufnr or not api.nvim_buf_is_valid(context_bufnr). So it must be invalid context_bufnr when issue produced.
When gutter_winid, context_winid, gutter_bufnr, context_bufnr are global, all buffers will use the same variables. And the invoked time and order of functions get_bufs(), delete_bufs(), open(ctx_nodes), close() may be random and multiple.
And the invoked callback of function update is uncertain. I think the issue will be produced when autocommands ('WinScrolled', 'BufEnter', 'WinEnter', 'VimResized', 'CursorMoved', 'WinLeave', 'SessionSavePre', 'SessionSavePost') triggered so invoke the callback of function update twice or more. The global variables (context_bufnr) will be changed in different buffers.
@romgrk So I think these variables should be buffer-local.
I see the issue now, I didn't expect us to be creating multiple buffers. I'm a bit worried that we're going to be creating buffers without cleaning them up, would that still be the case once this PR is merged?