Stylua wrong range in rangeForamtting

JoseConseco commented 2 years ago

FAQ

[X] I have checked the FAQ and it didn't resolve my problem.

Issues

[X] I have checked existing issues and there are no issues with the same problem.

Neovim Version

NVIM v0.7.0-dev+1129-g30c9c8815

Operating System

Linux (Manjaro)

Minimal config

it is not problem of config.

Steps to reproduce

second and third line have to big indent. I print row, --range-start, --range-end for easier debugging (from format_range ) :

https://user-images.githubusercontent.com/13521338/155889834-e1b39794-db34-4198-8a12-547359c169d8.mp4

At first format - range is ok (it matches selection),
after moving to 2nd line and formatting it - ranges were not updated - so stylua formats 3rd line again
after selecting first 3 lines, now - stylua range seems to affect only second row (see printed debug variables - 2row only) Its bit random, but ranges seems to not being updated properly when running range-format few times.

Expected behavior

Format second line, then third line only, then all three lines

Actual behavior

not format selection (only at first time)

Debug log

see video

Help

No

Implementation help

No response

Requirements

[X] I have read and followed the instructions above and understand that my issue will be closed if I did not provide the required information.

jose-elias-alvarez commented 2 years ago

This is a pretty strange issue and I'm not able to replicate it. Based on the video, it looks like the root cause is that the range itself wrong, but you're saying that it only happens with StyLua? Also, it's not clear from the video, but are you formatting with vim.lsp.buf.range_formatting() or something else?

The logic on our end is pretty simple–we take the original range, which is generated by Neovim, and convert it. I don't immediately see anything there that could cause the range to not update.

For now, I'd try logging the original range and making sure that it matches what you expect. I'd also try to see build the latest Neovim master and see if you can replicate it with a full minimal config (see the issue template) to rule out potential interference from other sources.

JoseConseco commented 2 years ago

The init file wont work for me (packer commands not deteced and I do not want to spend hour to make it work). I any case, is there some kind of caching in null-lsp or in vim.lsp? The reason in

if I try to format second line, then styluna null works ok
if I then try to format 3 line, then second line range is formatted again,
if I go to 5th line, then 4th line range gets formatted So it kind of 'lags' behind. I no one else can confirm then I can close this, as it may be indeed my setup problem.

jose-elias-alvarez commented 2 years ago

Assuming you are using vim.lsp.buf.range_formatting(), you can see that the params are generated each time (null-ls does not do any caching, either).

The util function referenced there gets start and end positions from the < and > marks, so I wonder if something could be going wrong there. You might want to try this with an actual LSP server that supports ranged formatting to verify that it's a null-ls issue.

JoseConseco commented 2 years ago

Yes I use range format. I checked prettier - which also uses h.range_formatting_args_factory on css and html and it seems to have similar issue - when debugging range variables - they 'lag' behind actuall selection. THe problem with prettier is that it does not work on ranger (event though their site says it does) - as you can see for yourself on their playground Only selecting whole doc - will resutl in formatted text. But that is their issue. BTw. I'm on latest daily nvim build.

tzachar commented 2 years ago

I can confirm the same problem with stylua. I am getting bogus ranges.

I think the problem is with builtins/formatting/stylua.lua, the following diff helps:

diff --git a/lua/null-ls/builtins/formatting/stylua.lua b/lua/null-ls/builtins/formatting/stylua.lua
index 47771bd..2d31e06 100644
--- a/lua/null-ls/builtins/formatting/stylua.lua
+++ b/lua/null-ls/builtins/formatting/stylua.lua
@@ -19,7 +19,7 @@ return h.make_builtin({
             "--stdin-filepath",
             "$FILENAME",
             "-",
-        }, "--range-start", "--range-end", { row_offset = -1, col_offset = -1 }),
+        }, "--range-start", "--range-end", { row_offset = -1, col_offset = -1, use_rows = true}),
         to_stdin = true,
     },
     factory = h.formatter_factory,

jose-elias-alvarez commented 2 years ago

I can confirm the same problem with stylua. I am getting bogus ranges.

I think the problem is with builtins/formatting/stylua.lua, the following diff helps:

diff --git a/lua/null-ls/builtins/formatting/stylua.lua b/lua/null-ls/builtins/formatting/stylua.lua
index 47771bd..2d31e06 100644
--- a/lua/null-ls/builtins/formatting/stylua.lua
+++ b/lua/null-ls/builtins/formatting/stylua.lua
@@ -19,7 +19,7 @@ return h.make_builtin({
             "--stdin-filepath",
             "$FILENAME",
             "-",
-        }, "--range-start", "--range-end", { row_offset = -1, col_offset = -1 }),
+        }, "--range-start", "--range-end", { row_offset = -1, col_offset = -1, use_rows = true}),
         to_stdin = true,
     },
     factory = h.formatter_factory,

I'm not sure this is the right fix. stylua --help specifies that --range-start and --range-end take byte offsets, so using rows doesn't seem right. I also don't think this would explain the OP's problem where the ranges aren't updated on a new visual selection.

tzachar commented 2 years ago

Yes, you are correct. I mistakenly thought it accepted rows.

jose-elias-alvarez commented 2 years ago

Is this still an issue for you guys? I can't replicate it with any of the sources that support range formatting that I've tested. There's no caching going on on either side, so I have no idea what could be causing this except for some kind of interference from another plugin. It'd be super helpful if you could give the minimal init file another try so that we could isolate the issue and try to find the cause.

JoseConseco commented 2 years ago

I will close this since it looks like config problem. I will let you know if I manage to fix this in future.

JoseConseco commented 2 years ago

@jose-elias-alvarez I managed to 'fix' the range format. The issue was my lsp-config. The official nvim lsp suggest using : buf_set_keymap("v", "<space>cf", "<cmd>lua vim.lsp.buf.range_formatting()<CR>", opts) But after reading stack overflow it is clear that range_format operates on last visual selection range. Thus to make it 'see' the current visual selection we just add esc in above mapping: buf_set_keymap("v", "<space>cf", "<ESC><cmd>lua vim.lsp.buf.range_formatting()<CR>", opts)

There is also trick in here to format using motions.

jose-elias-alvarez commented 2 years ago

Ahh I see, glad you were able to figure it out!

jose-elias-alvarez / null-ls.nvim