Sends extra blank line to stdin-reading linters about nvim-lint

[dimbleby]

I've just spotted that the unwanted trailing line was introduced at d6a76b3 to fix #131, so perhaps it's not so straighforward.

[mfussenegger]

Can you try with #145?

[dimbleby]

This works fine for me - but isn't it what we had before 7fb6ae1? Will this reopen #127?

[dimbleby]

Maybe something like this:

diff --git a/lua/lint.lua b/lua/lint.lua
index fee3ac7..4918463 100644
--- a/lua/lint.lua
+++ b/lua/lint.lua
@@ -165,10 +165,8 @@ function M.lint(linter)
   start_read(linter.stream, stdout, stderr, bufnr, parser, ns)
   if linter.stdin then
     local lines = vim.api.nvim_buf_get_lines(0, 0, -1, true)
-    for _, line in ipairs(lines) do
-      stdin:write(line .. '\n')
-    end
-    stdin:write('\n', function()
+    local content = table.concat(lines, '\n')
+    stdin:write(content .. '\n', function()
       stdin:shutdown(function()
         stdin:close()
       end)

I couldn't find a way of getting the actual content of the buffer rather than this line-by-line reconstruction, which seems to me unsatisfactory - eg what if the linter wants to warn you that you have mixed line endings? But perhaps this will do.

[mfussenegger]

This works fine for me - but isn't it what we had before 7fb6ae1? Will this reopen #127?

It's similar yes, but with the new PR the shutdown also uses the callback before invoking close.

Maybe something like this:

This also sends a trailing \n ? Not sure why it would be better than the status quo?

[dimbleby]

my version sent only a single trailing newline - which should be present in every posix-compliant file.

However if I'd misread your proposal and it's not going to re-break #127, it's all good - thanks!