by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Ashkan Kiani
@norcalli
Ah that's a fair point, buffer local variables.
It would be good to make that infrastructure easier to work with
fn/g/b as an analogy isn't bad
Christian Clason
@clason
It has a bit of a smell (there's a term for inheriting no longer necessary compromises for the sake of consistency), but it'd have the benefit of teaching vim api.
Ashkan Kiani
@norcalli
I agree.
Could also do fn/var/buf
Christian Clason
@clason
that'd be more expressive.
(but deviate from vim api)
trade-offs abound.
Ashkan Kiani
@norcalli
Ah you're giving me ideas.
Now I'm thinking having a buffer_local_mappings wouldn't be terrible either
And a buffer_setup
Christian Clason
@clason
optionally, if a plugin requires them
Ashkan Kiani
@norcalli
But no wait those would go with events, probably.
Or it could be a buffer_local = function(bufnr) return export { ... } where it exports a similar interface and is called inside of the buffer.
The plugin can just as easily return if it uses some criteria to say "I don't want to attach to this"
And it won't attach anything
btw, it should be assumed that I'll include a test suite to make sure all of this stuff works for plugin authors before they actually publish anything.
Just to validate things like buffer_local settings
Well maybe runtime errors are just inevitable
This isn't haskell
Christian Clason
@clason
yeah, can't account for a user's init.lua
but a convenient testing infrastructure for lua plugins would be huge.
Most plugins don't make the effort that vimtex does https://github.com/lervag/vimtex/tree/master/test
Ashkan Kiani
@norcalli
Yeah the benefit of standardizing is also making testing easier
oh my god
Christian Clason
@clason
it's even versioned now!
good stuff
Ashkan Kiani
@norcalli
You know what I'm realizing now
All of the lua mappings usually don't take arguments
Christian Clason
@clason
go on...
Ashkan Kiani
@norcalli
So I could do stuff like pass them buffer local state
Simply the per-buffer configuration stuff
Like for doing per-buffer overrides.
Christian Clason
@clason
that sounds dangerously magical...
but I understand literally no part of this :)
Ashkan Kiani
@norcalli
Yeah I'd be worried about too much magic, but the function argument part is free real estate right now
This is from my colorizer, so it's clearly a bit of cruft you likely want to do
Christian Clason
@clason
Syntactic sugar is nice, but too much can give you syntactic diabetes :)
(but, yeah, buffer-local things can definitely be useful)
Ashkan Kiani
@norcalli
I need to actually use this with a real plugin I wrote
Maybe nvim-lsp...
Since it's probably the most complicated.
Christian Clason
@clason
I wanted to suggest that as well, showing off the infrastructure on a live subject; it doesn't have to replicate all functionality from the original one (nvim-completion or -- probably easier -- nvim-diagnostics would be an option as well)
But first, I distinctly remember being promised snippets :P
Ashkan Kiani
@norcalli
My snippets wouldn't be a bad one to test either, but I wanted something with more commands
Christian Clason
@clason
probably better to test-drive this on a fork rather than a plugin people actually use ;)
Ashkan Kiani
@norcalli
I was trying to fix one more test case before pushing
Christian Clason
@clason
no hurry.