feat(lua): add buflocal

[mfussenegger]

This is currently more of a proof of concept to get some feedback on whether
this is a horrible idea, or somewhat reasonable.

I was mostly interested if this is possible at all and Justin mentioned using
b: elsewhere, which afaik has some vimscript marshalling limitations for some
types(?) and you cannot keep state completely hidden as implementation detail.

I'm also not yet sure if this can cover most cases. If there's positive feedback I'd try and convert some more spots, otherwise 🚮

---

There are a few modules, each of which is managing state per buffer and
duplicating logic like cleanup.
Properly cleaning up can be tricky - see:

f32fd19

This introduces a Buflocal inspired by thread-local storage:

https://en.wikipedia.org/wiki/Thread-local_storage

The Buflocal can be used to access state for a buffer, which gets
cleaned up if the buffer is deleted.

(Although the name here may be a bit misleading - as the buffer number is parameterized and you can get the state of other buffers, not just current. )

[justinmk]

Justin mentioned using b: elsewhere, which afaik has some vimscript marshalling limitations for some types(?) and you cannot keep state completely hidden as implementation detail.

See #12544 (comment) for my proposal. If possible, I think it's ideal that we keep vim.b/vim.w/etc as the interface for "state that is bound to the lifecycle of the object". I don't see marshalling limitations as a problem, because that only matters if Vimscript requests the state, and it can simply get a degraded form of the state.

[mfussenegger]

I don't see marshalling limitations as a problem

👍

If possible, I think it's ideal that we keep vim.b/vim.w/etc as the interface for "state that is bound to the lifecycle of the object".

That would also imply that the state is always public, no? I imagine diagnostic_cache in vim.diagnostic would then be exposed as vim.b.vim_diagnostic_cache or something?

---

On second thought, the buflocal might actually be closer to a vim.defaulttable(), so it could also be some kind of vim.buftable(), that behaves more like a table with tbl[bufnr] index access.

[ii14]

on_detach runs on just rereading the file with :e (btw shouldn't nvim_buf_attach run on_reload in this case, or am I misremembering how it works?), so variables can be removed too soon.

Events on the other hand can be silenced (explicitly with :noau, eventignore or most often just because they were emitted inside some other autocmd and someone forgot to mark it nested). And it does happen in practice - I similarly maintain my own buffer list and it occasionally goes out of sync precisely because of nested autocmds being silenced by default somewhere.

As far as I know, there is no mechanism that lets you do this robustly right now?