Stylua Tab Formatting
tris203 opened this issue · comments
FAQ
- I have checked the FAQ and it didn't resolve my problem.
Issues
- I have checked existing issues and there are no issues with the same problem.
Neovim Version
0.10.0-dev
Dev Version?
- I am using a stable Neovim release version, or if I am using a dev version of Neovim I have confirmed that my issue is reproducible on a stable version.
Operating System
Ubuntu
Minimal Config
builtins.formatting.stylua
Steps to Reproduce
Attempt to format this code
M = {}
function M.find_duplicates(table1, table2)
for _, v in pairs(table1) do
for _, v2 in pairs(table2) do
if
M.sanitise_modifier_keys(v.prop1)
== M.sanitise_modifier_keys(v2.prop1)
and v.prop2 ~= v2.prop2
then
return true
end
end
end
end
return M
column_width = 80
line_endings = "Unix"
indent_type = "Spaces"
indent_width = 4
quote_style = "AutoPreferDouble"
the if statement indenting on line 7 is missing a tab
Reproducibility Check
- I confirm that my minimal config is based on the
minimal_init.lua
template and that my issue is reproducible by runningnvim --clean -u minimal_init.lua
and following the steps above.
Expected Behavior
to be formatted
== M.sanitise_modifier_keys(v2.prop1)
Actual Behavior
Formatted
== M.sanitise_modifier_keys(v2.prop1)
Debug Log
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/rpc.lua:106: received LSP request for method textDocument/formatting
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/generators.lua:21: running generators for method NULL_LS_FORMATTING
[DEBUG Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:329: spawning command "stylua" at /home/tris/code/hawtkeys.nvim with args { "--search-parent-directories", "--stdin-filepath", "/tmp/random.lua", "-" }
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:207: error output: nil
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/helpers/generator_factory.lua:208: output: M = {}
function M.find_duplicates(table1, table2)
for _, v in pairs(table1) do
for _, v2 in pairs(table2) do
if
M.sanitise_modifier_keys(v.prop1)
== M.sanitise_modifier_keys(v2.prop1)
and v.prop2 ~= v2.prop2
then
return true
end
end
end
end
return M
[DEBUG Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/formatting.lua:89: received edits from generators
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/formatting.lua:90: {
newText = " ",
range = {
["end"] = {
character = 16,
line = 7
},
start = {
character = 16,
line = 7
}
},
rangeLength = 0
}
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/rpc.lua:131: received LSP notification for method textDocument/didChange
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/generators.lua:21: running generators for method NULL_LS_DIAGNOSTICS
[DEBUG Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/generators.lua:24: no generators available
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/rpc.lua:131: received LSP notification for method textDocument/didChange
[TRACE Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/generators.lua:21: running generators for method NULL_LS_DIAGNOSTICS
[DEBUG Fri 05 Jan 2024 20:41:14 GMT] /home/tris/.local/share/nvim/lazy/none-ls.nvim/lua/null-ls/generators.lua:24: no generators available
Help
Yes
Implementation Help
I am not sure if this is a none-ls bug, or a upstream nvim bug to do with writing the text back into the buffer
Requirements
- I have read and followed the instructions above and understand that my issue will be closed if I did not provide the required information.
Try invoking the stylus CLI manually and see if the behavior changes.
It does. From the stylua CLI it works correctly
Seems like I'm getting the same thing. @tris203 does formatting the first time after opening work? The first time after I open neovim the format always works. After that first one it doesn't work at all and I get the same no generators available
log errors until I restart neovim.
Running the stylua CLI outside of neovim works every time.
I'm on neovim 0.9.5.
Seems like I'm getting the same thing. @tris203 does formatting the first time after opening work? The first time after I open neovim the format always works. After that first one it doesn't work at all and I get the same
no generators available
log errors until I restart neovim.Running the stylua CLI outside of neovim works every time.
I'm on neovim 0.9.5.
I don't think any of them work for me
Additionally, if I use the CLI to format it. None-ls will then reformat it to be wrong
Could anyone reproduce this on older Neovim releases?
Could anyone reproduce this on older Neovim releases?
I need to test again. But I wasn't having issues the other day in nightly. So it's possible this was an upstream nightly bug which has been resolved
I'm not sure if this is the right issue, but I thought I'd put this here before opening a new one. Let me know if you'd rather have me open a new one:
Formatting with stylua doesn't seem to be respecting stylua.toml
, .stylua.toml
or .styluaignore
on the cwd
where nvim
was run. I've tried on two different projects, each with different .stylua.toml
files, one with .styluaignore
on them. Regardless of what's on the stylua.toml
on cwd
, buffer is formatted the same, and it is formatted even if it's on the local .styluaignore
(I'm even passing --respect-ignores
as an extra_args
). Hadn't tried with config files before, but formatting with stylua via conform.nvim
(which I was using before configuring stylua with null-ls
) was respecting the local .styluaignore
. Could it be something to do with how the command is being called?
Let me know what extra info I can get for you.
I'm pretty sure this was an upstream issue which has been fixed now
Closing