ref!: major refactor

[xiaoshihou514]

closes #68 #86 #123 #109 #76 #141 #111

changes

• remove uv.spawn wrapper in favour of vim.system
• do_lint now respects all config fields
• linter can now use lnum_end and col_end
• added step by step tutorial for advanced usage
• remove all version checking code, only supports 0.10+ from now on
• apply exepath fix for windows

internal changes

• events now contains truly all autocmd related functions
• utils now contains execution checking functions
• use custom simpler table copy

[glepnir]

the main idea of there i think we can now remove the custom spawn logic and move to vim.system with coroutine wrapper.

[xiaoshihou514]

I can try...

[xiaoshihou514]

The main thread is still blocked on api.nvim_buf_set_lines(...), any way around it?
Seem to apply to current version as well

[xiaoshihou514]

TODO: make linters support all config fields

[yebt]

<3
I'm going to love this plugin, thank you very much

[glepnir]

nice work. some edge cases can fix in later.

[anna328p]

hi hello you accidentally started writing double newlines to the linter (guard.nvim adds a newline to the end of each line in https://github.com/nvimdev/guard.nvim/blob/main/lua/guard/util.lua#L9-L16, and then nvim's SystemObj:write() adds a newline to the end of every line it writes, see https://github.com/neovim/neovim/blob/5331f87f6145f705c73c5c23f365cecb9fbc5067/runtime/lua/vim/_system.lua#L122-L125) which means the linter gets line numbers wrong and keeps complaining about there being too many newlines.

[xiaoshihou514]

hi hello you accidentally started writing double newlines to the linter (guard.nvim adds a newline to the end of each line in https://github.com/nvimdev/guard.nvim/blob/main/lua/guard/util.lua#L9-L16, and then nvim's SystemObj:write() adds a newline to the end of every line it writes, see https://github.com/neovim/neovim/blob/5331f87f6145f705c73c5c23f365cecb9fbc5067/runtime/lua/vim/_system.lua#L122-L125) which means the linter gets line numbers wrong and keeps complaining about there being too many newlines.

Oh wow nice catch! That explains why clippy always reports the double amount of line number.

I will push a fix tonight after some more testing.