Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiline comments, indent after closing "]]" is unstable #170

Closed
notpeter opened this issue Apr 16, 2024 · 7 comments · Fixed by #172 or LuaLS/lua-language-server#2678
Closed

Multiline comments, indent after closing "]]" is unstable #170

notpeter opened this issue Apr 16, 2024 · 7 comments · Fixed by #172 or LuaLS/lua-language-server#2678
Labels
discuss question Further information is requested

Comments

@notpeter
Copy link
Contributor

Take this code block:

--[[
hello
world
]]--

Run Format and EmmyLuaCodeStyle Style changes it to:

--[[
poop
crap
]]
   --

Format a second time changes it again:

--[[
poop
crap
]]
--
  1. Ideally I'd love EmmyLuaCodeStyle to leave the first block unchanged.
  2. Even if not, formatted output should probably be stable such that format(format(code)) == format(code)

Thanks!

@CppCXY
Copy link
Owner

CppCXY commented Apr 17, 2024

keep a stable formatting result is challenging, as I've chosen to determine the output based on the input, but I can assure that the result will be stable after multiple (2 times) formatting.

As for maintaining the original result you mentioned, it's not feasible. It itself is two comments, it will at least be affected by the distance of the comments, and this requirement is rare. For emmylua, there is almost no need to use long comments.

@CppCXY CppCXY added question Further information is requested discuss labels Apr 17, 2024
@notpeter
Copy link
Contributor Author

notpeter commented Apr 17, 2024

I see. EmmyLua detects it as two distinct statements. The ]] is the end of an expression and the -- is a new comment statement. I only recently realized that without the second -- the remainder of that line is no longer commented out!

For emmylua, there is almost no need to use long comments.

Yeah, I rarely use multiline comments, but sometimes see codebases where they are common at the tops of files and to comment-out large blocks of code.

[...] I can assure that the result will be stable after multiple (2 times) formatting.

I totally agree stable formatting can be challenging. I wonder whether it would be feasible to have this lib (or LuaLS as caller) to run the Format twice to increase the likelyhood of stable output.

I only encountered this issue after using an editor (Zed) which defaulted to Format on Save. I then made some unrelated edits and the second save-and-format made additional unexpected changes.

I know that this code has had an explosion of new users with the growth and popularity of LuaLS and a pent-up demand for better Lua tooling in general. I appreciate you building and sharing such a great tool. Thanks.

@CppCXY
Copy link
Owner

CppCXY commented Apr 17, 2024

Although formatting twice can reduce this situation, I don't want to do such a thing, because for most cases, only one formatting is needed. I remember that clangformat still needs to format twice in some cases, I think this situation is quite common.

Although my tool is known for being the default formatter for luals, it was originally designed for emmylua, I don't know if you've heard of it. In fact, I'm also developing a new lua analyze lib and ls.

@notpeter
Copy link
Contributor Author

notpeter commented May 1, 2024

I feel you. Formatting twice is a pretty ugly hack, but the lack of stable formatting means it can't be used to enforce a code style (pre-commit hook, CI check, etc) and you can't rely on Format-On-Save to automagically to do the right thing by default.

I had heard of EmmyLua and used a bit in IntelliJ before moving to LuaLS+VSCode. In may not be clear to most folks that LuaLS Type Annotations are largely just EmmyLua annotations with some "differences". I've been impressed with the adoption of LuaLS but have observed there is significant unnecessary complexity throughout LuaLS and sumneko.lua which makes contribution difficult. Also, I'm sure that the vast majority of users don't know that LuaLS bundles privately compiled binaries of an obscure Lua fork bee.lua with patches. This would be an easy target for an xzutils style supply chain attack -- 1.2M installs of the VSCode extension and very few eyeballs on the process.

I had not seen EmmyLuaAnalyzer. I'm excited that you are you taking a crack at a clean implementation and to see where it goes.

@notpeter
Copy link
Contributor Author

notpeter commented May 1, 2024

btw, are you are aware of any other case where Format requires multiple passes or is otherwise unstable?

@CppCXY
Copy link
Owner

CppCXY commented May 1, 2024

My formatter is not only suitable for Sumneko, it can be compiled into a dynamic library and programmed by the standard Lua require. In addition, my release provides an independent formatter that you can solve these problems by passing shell parameters. If you want to use it for CI, my formatter comes with a check algorithm that does not require comparison after formatting

@CppCXY
Copy link
Owner

CppCXY commented May 1, 2024

Thank you for mentioning emmyluaanalyzer. I developed this project for better language server performance and easier to use APIs. It is now basically compatible with Luals syntax. If you have the opportunity, you can give it a try

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss question Further information is requested
Projects
None yet
2 participants