Skip to content

Conversation

@patrickeibl
Copy link

Resolves #55

An excess of indexed buffers can cause performance issues with buffer completion. If the user tries to limit the number of indexed buffers using get_bufnrs(), the old buffers are still retained when not specified in that function until they are wiped out. The workaround as discussed in #40 is to wipeout the old buffers, which is the only way to guarantee that indexing stops.

This PR calls close() on any buffers previously indexed but not returned in a subsequent get_bufnrs() call.

@hrsh7th
Copy link
Owner

hrsh7th commented Jul 27, 2022

LGTM.
I'll try this on my local environment a bit.

@bew
Copy link

bew commented Mar 12, 2023

Isn't this problematic when our get_bufnrs function is context dependent?
For example depending on the currently visible buffers, or the current buffer filetype.

With the example of visible buffers, if in a tab, I get completions(with indexing), I switch to another tab, I get completion(with indexing), I go back to previous tab: I'll need to re-index buffers?

@patrickeibl
Copy link
Author

When and how is it context dependent?

It looks like the original code assumes a static mapping of buffer numbers to open buffers, so mine does as well.

@hrsh7th
Copy link
Owner

hrsh7th commented Mar 13, 2023

Certainly, if get_bufnrs changes the return value depending on the context, the deleted buffer will be re-indexed, so it seems to affect the CPU.

google translated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Buffers are only added and not removed

3 participants