vim-lsp icon indicating copy to clipboard operation
vim-lsp copied to clipboard

Unusable file-marks "VS.Vim.Buffer.Default" building up in viminfo

Open dezza opened this issue 2 years ago • 1 comments

https://github.com/prabirshrestha/vim-lsp/blob/14f9ab319ff96eea16ef6dbf57ed801c8fc8967e/autoload/vital/_lsp/VS/Vim/Buffer.vim#L54

The above line adds a named buffer. Since only unnamed buffers are skipped by viminfo vim-lsp leaves file-marks in viminfo when enabled. This seems unnecessary for a temporary buffer, and 'viminfo'-option is global-only with no buffer-local equvalent. There is only :help viminfo-r-flag for excluding paths which only works with real files (and can't use globbing to work around it afaik, I have tried).

You can find entries such as:

> ~/VS.Vim.Buffer: 1: VS.Vim.Buffer.Default
        "       1       0

The name here is VS.Vim.Buffer: 1: VS.Vim.Buffer.Default and appears after starting an empty vim session (the hidden buffer is available on :b 2 in empty vim-session or can be shown with :ls!.

This also affects other functionality such as v:oldfiles, :browse oldfiles that uses viminfo file-marks to build the list.

Since the name includes buffer-id, this will grow over time. But these temporary buffers have never been files and the file-marks has no use.

If started in another directory ~/src/vim/, its starting to build up another pile under a new namespace.

> ~/src/vim/VS.Vim.Buffer: 1: VS.Vim.Buffer.Default
        "       1       0

There is no obvious workaround to this as as there is no way to control which named buffers vim saves file-marks for.

An alternative could be global variables (viminfo-!), if this needs to be stored.

dezza avatar Jul 17 '22 20:07 dezza

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Sep 21 '22 00:09 stale[bot]

Bump

dezza avatar Oct 18 '22 01:10 dezza

Can you try sending PR here first? https://github.com/hrsh7th/vim-vital-vs

prabirshrestha avatar Oct 18 '22 01:10 prabirshrestha

@prabirshrestha https://github.com/hrsh7th/vim-vital-vs/pull/22

dezza avatar Oct 18 '22 13:10 dezza

Finally, I understand the problem. I'll look this.

hrsh7th avatar Oct 18 '22 14:10 hrsh7th

Alright! I'll be here if you need me.

@romainl and me had a chat about this, I thought you'd appreciate this, even if he does not think it seems like an issue I'm certain I tested it in multiple ways last time I tested. I tried just now (after not sleeping for 18hrs, so bear with me....)

08:56 <romainl> dza: I couldn't help but think about that viminfo issue
08:57 <dza> romainl: I'm certain I tested it, I'm not sure why you could not reproduce.
08:58 <romainl> the filename is known when doing :badd so how about adding it dynamically to viminfo-r ?
08:58 <romainl> I could reproduce, I have two kids
08:58 <romainl> ;-)
08:59 <dza> VS.Vim.Buffer children?
09:01 <romainl> If you don't edit the :badd-ed buffer then it is not added to viminfo. That I was able to reproduce. The workaround, I think, is to explicitly exclude the buffer name with viminfo-r since the name is known when the plugin does :badd.
09:02 <romainl> on subsequent edits, the file mark won't be set because the filename is blacklisted
09:07 <romainl> another, deeper but possibly simpler, workaround would be prefix the buffer name with an imaginary path like /tmp/my-lsp-plugin and add it to viminfo-r only once.
09:08 <romainl> see also :h tempname()

I could avoid the issue with set viminfo+=r~/*/VS.Vim*

@romainl pointed out he could do without the globs, (I personally couldn't get it to work)

21:34 <dza> romainl: set viminfo+=r~/*/VS.Vim* ?
21:35 <romainl> without ~/*/ and *

Nevertheless I don't see a reason why this should be a solution (with viminfo-r)

dezza avatar Oct 18 '22 14:10 dezza

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jan 07 '23 18:01 stale[bot]