functions for statusline components

[anott03]

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.

[wbthomason]

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

[wbthomason]

I'd prefer that the fallback icon here come from config, e.g. config.indicator_errors. Same comment for the other functions.

[wbthomason]

We could reduce some code duplication by making a factory function make_statusline_component, parameterized on a fallback icon and diagnostics key, that returns a function of the form of these new functions. This would also make it easier to add future statusline components (e.g. for info).

[anott03]

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]

@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]

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]

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]

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]

It works!

[anott03]

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]

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]

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

[wbthomason]

Looks good, thank you!