ref!: major refactor - Githubissues

nvimdev / guard.nvim

async fast minimalist plugin make format easy in neovim

MIT License

448 stars 24 forks source link

ref!: major refactor #150

Closed xiaoshihou514 closed 3 months ago

xiaoshihou514 commented 4 months ago

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

changes

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

internal changes

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

glepnir commented 4 months ago

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

xiaoshihou514 commented 4 months ago

I can try...

xiaoshihou514 commented 4 months ago

~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 commented 4 months ago

~TODO: make linters support all config fields~

glepnir commented 4 months ago

seems like need more test cases.

xiaoshihou514 commented 4 months ago

glepnir commented 3 months ago

test cases for new vim.spawn wrapper. single tool multiple tools etc case.

xiaoshihou514 commented 3 months ago

test cases for new vim.spawn wrapper. single tool multiple tools etc case.

Do I just assert true like in previous test?

glepnir commented 3 months ago

that's too simple It's better pass some codes as stdin then check result.

yebt commented 3 months ago

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

anna328p commented 3 weeks ago

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 commented 2 weeks ago

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.