Ability to only get portions of the statusline

[sharksforarms]

Thanks for the great plugin!

It would be nice to be able to have a function to get only a portion of the status line segments to enable further customization. For example, I'm only interested in the spinner portion, would be great to have a function which only returns this.

[wbthomason]

Thanks! The statusline implementation is really meant as a proof of concept/an out-of-the-box default. If you'd like to pull out the relevant parts of the current implementation into their own function, I'd be happy to merge that PR. I'm not likely to get to making that refactor myself anytime soon, however.

If you do decide to pursue the PR route, let me know if you have any questions, etc. - I'd be happy to provide guidance.

[anott03]

I believe #39 closes this, unless there is more functionality we want to make available as it's own function.

[sharksforarms]

I believe #39 closes this, unless there is more functionality we want to make available as it's own function.

Hey @anott03 would you be able to provide an example usage? Is this using the _get_component_functions function?

[anott03]

@sharksforarms my configuration looks like this:

local lspstatus = require('lsp-status')

return table.concat({
  mode, git, filename, '%=',
  lspstatus.status_hints() .. ' ',
  lspstatus.status_warnings() .. ' ',
  lspstatus.status_errors(),
  ' | ', '%p%%', filetype
})

(the things that aren't lsp-status related are variables defined in my config)

_get_component_functions is a generator function that creates the status_X functions but is not how they should be accessed. The generator is called during initialization (because the status_X functions rely on the config they can't be created before configuration is done) and the functions it creates are added to the statusline table and ultimately exported to be used as you see in my config above.

Note: in addition to the three functions I use, lspstatus.status_info() is also available.

[wbthomason]

(Noting that I'm leaving this to @sharksforarms to close if they agree that #39 resolves this)

[sharksforarms]

This solves most of it! I still think the spinner should be part of this? @anott03 Great job on #39, very simple solution!

[akinsho]

Just discovered this issue having tried to find a way to extract just the progress indicator and current function (+spinner which I assume is built into the progress indicator). It doesn't appear that it could be exposed using the exact same mechanism as the other status_x functions. @anott03 given you wrote the original PR any ideas how this could be extracted into a function? I was thinking of just making the progress bits a module variable that's exposed through a function but not using the _get_component function since that's quite specific to diagnostics

[wbthomason]

@akinsho: It should be possible to pull https://github.com/nvim-lua/lsp-status.nvim/blob/master/lua/lsp-status/statusline.lua#L42 and https://github.com/nvim-lua/lsp-status.nvim/blob/master/lua/lsp-status/statusline.lua#L75-L105 together out into their own "just messages" function (including the spinner), which I think would work for your case (we could also refactor the spinner out if people want that separately from the progress messages).

For the current function, you can just read vim.b.lsp_current_function, as in https://github.com/nvim-lua/lsp-status.nvim/blob/master/lua/lsp-status/statusline.lua#L110

[akinsho]

I just opened #58 @wbthomason which does what you described 👍🏾

[wbthomason]

Thanks! I've merged #58, so I think this is now closed?