Closed tjdevries closed 4 years ago
Hmm. I like this idea, but I want to think about how best to structure it. For one thing, I think it'll make sense to add a mechanism for "extension"/"suggested" modules to add default configuration values. There's also a question (for the statusline stuff in particular) of how to best organize code that needs to be inserted in multiple places (e.g. the statusline code has components in on_attach
, in init.lua
or equivalent, and in wherever you create your statusline).
Thanks for the suggestion! I did something like this in e0af53b and 8fb7cc4. I opted against a "shared" module for the time being, though I'd reconsider if more of this sort of functionality gets added to the plugin. Instead, I made a statusline
module and exposed a status
function from the main module, as well as making a number of improvements to the setup process (i.e. creating an on_attach
function to handle registration and setting up autocommands, creating setup
functions for the extensions to avoid needing to enumerate callbacks) to make things easier to use. Let me know if this isn't quite what you had in mind. Thanks again!
Since the functions you have in the README are cool, I'd suggest moving them to some shared "suggested" lua file, where you can just do
require('lsp-status.shared').statusline()
as opposed to directly copying it, in case something changes or you have updates, etc.I ended up copying most of the code directly into my init.vim, so it might be nice to make it so that any improvements you make are automatically moved to user's config.
Additionally (with the cool thing you have with extensions) I could see other small things getting added (like the sumneko callback I had to add, for example) that might be useful for many people to "just work".
Just a thought. You can close if you don't want to manage all of that :D