nvim-lua / lsp-status.nvim

Utility functions for getting diagnostic status and progress messages from LSP servers, for use in the Neovim statusline
MIT License
625 stars 41 forks source link

functions for statusline components #39

Closed anott03 closed 3 years ago

anott03 commented 3 years ago

I wanted to be able to easily access just the warnings, errors, etc. for a given buffer so I wrote these functions. I think others might find them useful.

anott03 commented 3 years ago

Thanks for this! I left a few comments (mostly regarding style) in the changes - please let me know what you think.

These all make sense. I'll work on implementing them.

anott03 commented 3 years ago

@wbthomason this is what I've done so far:

local function make_statusline_component(diagnostics_key)
  return function(icon, bufh)
    bufh = vim.api.nvim_get_current_buf()
    local buf_diagnostics = diagnostics(bufh)
    local val = buf_diagnostics[diagnostics_key]
    return icon .. val
  end
end

local M = {
    ...
    errors = make_statusline_component('errors')
}
...

Is this along the lines of what you were thinking, or do you think the user should call make_statusline_component? Also, how were you thinking of getting the default icon based on diagnostics_key, given that config has attributes for each icon rather than a table that I can access the way I access values in buf_diagnostics?

wbthomason commented 3 years ago

Yep, that's what I was suggesting. Regarding the default icon, I was actually suggesting that the signature of the factory function be more like make_statusline_component(diagnostics_key, fallback_icon), to be used like make_statusline_component('errors', config.indicator_errors).

However, it's also worth noting that, in Lua (without metatable customization), "attributes" and keys are (mostly) identical. That is, config.indicator_errors and config['indicator_errors'] are the same thing. So, you could avoid adding a second parameter with config['indicator_' .. diagnostics_key].

anott03 commented 3 years ago

you could avoid adding a second parameter with config['indicator_' .. diagnostics_key]

Of course! I can't believe I didn't think to do that :)

I'm having a different issue now: no matter what I do, the config table is always empty. I've called the main config function, but even after that call config in statusline.lua is still an empty table. Do you know why that might happen?

wbthomason commented 3 years ago

Ah, that one's on me - since the factory is called at require time, the config table is empty when the functions get evaluated. You could work around this by either duplicating the indicator_X keys in the local config table, or (probably the better approach) initialize the statusline_X functions in init().

anott03 commented 3 years ago

It works!

anott03 commented 3 years ago

Regarding the default icon, I was actually suggesting that the signature of the factory function be more like make_statusline_component(diagnostics_key, fallback_icon), to be used like make_statusline_component('errors', config.indicator_errors).

I don't think we need fallback_icon at all if we're grabbing the icon from config... the user can just set the icon they want through the config, and we can get the default icon from there as well.

wbthomason commented 3 years ago

Yep! Sorry, I was unclear - I meant the fallback_icon and string concat (i.e. config['indicator' .. diagnostics_key]) approaches to be two alternatives, rather than to be combined.

anott03 commented 3 years ago

@wbthomason I believe it's in a good spot now, and ready for you to check when you have time.