I observed that when using linters capable of reading from stdin (linter.stdin = true), opening the stdin pipe causes the vim.fn.getqflist function to return an incorrect buffer number (bufnr) for the parsed items. Specifically, with a fresh instance of neovim with only one file, the linted file has bufnr = 1, but the vim.fn.getqflist function outputs items with bufnr is set to an arbitrary value like 3 or 4. This is likely a neovim bug.
if item.valid == 1 and (bufnr == nil or item.bufnr == 0 or item.bufnr == bufnr) then
Current Workaround
As a temporary workaround, I bypass the additional conditions on the bufnr check and benefit from TextChanged (debounced) without further issues.
Suggestion
You could either report upstream this issue (you will likely have more impact than a random person like me), or relax the filtering conditions when iterating over the items parsed by getqflist. WDYT?
Hi @mfussenegger , thanks for this great plugin.
I observed that when using linters capable of reading from stdin (
linter.stdin = true), opening thestdinpipe causes thevim.fn.getqflistfunction to return an incorrect buffer number (bufnr) for the parsed items. Specifically, with a fresh instance of neovim with only one file, the linted file hasbufnr = 1, but thevim.fn.getqflistfunction outputs items withbufnris set to an arbitrary value like 3 or 4. This is likely a neovim bug.This incorrect
bufnrcauses all parsing results to be discarded due to the additional conditions in theon_errorformatfunction (https://github.com/mfussenegger/nvim-lint/blob/master/lua/lint/parser.lua#L21):Current Workaround
As a temporary workaround, I bypass the additional conditions on the bufnr check and benefit from TextChanged (debounced) without further issues.
Suggestion
You could either report upstream this issue (you will likely have more impact than a random person like me), or relax the filtering conditions when iterating over the items parsed by
getqflist. WDYT?Best and thanks again for your work!