How to reliably get number of errors from after diagnositcs?

[fedeDev]

I want to display the number of errors reported by LanguageClient-neovim using vim-arline. What I have right now is:

function! AirlineInit()
  let g:airline_section_x = airline#section#create(['LC_status'])
  let g:airline_section_error = airline#section#create(['LC_error_count'])
endfunction

call airline#parts#define_function('LC_error_count', 'LC_error_count')
call airline#parts#define_function('LC_status', 'LC_status')

function! LC_error_count()
  let count = len(getqflist())
  return count > 0 && g:LanguageClient_loaded ? 'E: ' . count : ''
endfunction

function! LC_status()
  return g:LanguageClient_loaded ? LanguageClient#statusLine() : ''
endfunction

autocmd User AirlineAfterInit call AirlineInit()

This is great for the LanguageClient#statusLine(), however I am currently relying on len(getqflist()) to get the number of errors from LS.

Is there a better way to get this number of diagnostic errors in order to use them in the status line?

Thanks!

[autozimu]

You could make use of this autocmd event

LanguageClient-neovim/doc/LanguageClient.txt

Line 415 in 6c545eb

5.3 LanguageClientDiagnosticsChanged

[fedeDev]

Yes, that would help triggering for refreshing airline. Is there any other way to expose the diagnostics extracted by LanguageCient? My "count size of quick fix" is error prone and hacky.

[autozimu]

Can you elaborate why it is error prone?

[autozimu]

This latest commit changed the way quickfix is updated. 5a12d70#diff-ba80c739c25b55f01f58c3724bcc93ddR1623

Not sure how much it will help your usage though.

[fedeDev]

Counting the elements of the quickfix is only useful if I'm only using the quickfix for LanguageClient-neovim. Any other plugin populating the quickfix would make my hack useless. Furthremore, I can no longer use the option of changing diagnostics report to display on the location list in the future.

Airline/lightline are very popular plugins, and I'm sure people will want to have this functionality in the future (YCM, Syntasic, ale, etc. already have this as part of airline). Simply exposing the number of diagnostic errors through a global variable (as done with LanguageClient#statusLine(), for example) would be a great start.

I am sorry not to be able to easily help with a PR, but I have never used Rust before :(

[autozimu]

I agree it would be nice to export those variables, which could make better integration with airline/lightline possible.

Just off the topic a bit, this plugin assumes sole owner of quickfix/location list. Not sure how it goes if there is another plugin modifying quickfix/location list at the same time.

[fedeDev]

OK, good to know. Another problem. Perhaps it is from the recent changes you mention (5a12d70#diff-ba80c739c25b55f01f58c3724bcc93ddR1623) but since the diagnostic errors are now global (all files report to the same quickfix), my way of counting errors (using quickfix count) is no longer relevant for the current buffer (as is the case for ale, ycm, etc).

[autozimu]

Yes, it is for project from now on.

[fedeDev]

I see, thanks. The issue now becomes: How can I get the number of diagnostic errors for the current buffer? I think this is the more useful functionality in the context of updating a neovim statusline.

Thanks for the quick replies!

[autozimu]

It could be done by matching quickfix list filename property.

[fedeDev]

Ok, I will try to implement that and will post here for future reference.

[autozimu]

I'm closing this one as there is nothing to be done from this project's perspective. Feel free to follow the comment or add it to the wiki whenever you get it working.

[blahgeek]

I would also like to display separate numbers of errors and warnings in status line. I understand that this can also be done by matching quickfix list keyword, but a function providing those numbers would be more efficient and easier to use.

EDIT: My bad. I though getqflist() returns plain strings and one need to use regex to match errors and warnings. I now find out that it returns dictionaries with type field. Now I think it's sufficient enough. Maybe there is nothing to be done in this project.