EmmyLuaCodeStyle icon indicating copy to clipboard operation
EmmyLuaCodeStyle copied to clipboard

Aligning align_continuous_inline_comment does not move the comment after the first formatting

Open TIMONz1535 opened this issue 11 months ago • 7 comments

The align_continuous_inline_comment = true does not move the comment to correct place after the first formatting the value align_continuous_assign_statement can be any true/false

local t  = 123
local cccc = 456
cccc = 321
-- this is a comment
eeeeeeeee                   = 654 -- this is a comment2

local t  = 123
local cccc = 456
cccc = 321-- this is a comment
eeeeeeeee                   = 654 -- this is a comment2

you need to format document for a second time

https://github.com/user-attachments/assets/028308c9-ea2c-4b3b-925e-ca935337aaae

https://github.com/user-attachments/assets/d6467500-2caa-4edd-96a7-0feaafcda66a

TIMONz1535 avatar Feb 11 '25 03:02 TIMONz1535

All alignments are like this, and the formatting options interact with each other, even conflict with each other. I cannot consider all situations when formatting

CppCXY avatar Feb 11 '25 05:02 CppCXY

From an implementation perspective, unless I can get a syntax tree that can be edited in real-time, further implementing formatting is very difficult. However, my Rust library can indeed get a syntax tree that can be edited in real-time, But I don't have time to reimplement a formatter.

CppCXY avatar Feb 11 '25 05:02 CppCXY

All alignments are like this, and the formatting options interact with each other, even conflict with each other. I cannot consider all situations when formatting

Oh, I think I was a bit wrong. The parameter align_continuous_assign_statement has no effect, but yes it is closely related. In my example I just made a lot of spaces before value and align_continuous_inline_comment = true then we see a bug. So align_continuous_assign_statement can be any true/false.

It removes the spaces before the value, but aligns the comments positions relative to its original position before removing the spaces, I'm guessing it might just be mixed up internal "pos variables".

TIMONz1535 avatar Feb 13 '25 04:02 TIMONz1535

This also doesn't take into account the value of tab_width, how it looks with 4 for example

local a = 1        -- text AAA
local b = 22222222 -- text BBB
do
	local a = 1     -- text AAA
	local b = 22222222 -- text BBB
	do
		local a = 1  -- text AAA
		local b = 22222222 -- text BBB
	end
end

Image

TIMONz1535 avatar Mar 02 '25 09:03 TIMONz1535

You are right, but I don't have time to work on this project anymore. It would be even better if you could submit a PR to fix it.

CppCXY avatar Mar 02 '25 09:03 CppCXY

I think it's not very good for me to say it directly like this, but regarding the issue you raised, I've already mentioned that the first problem cannot be resolved. As for the second issue, I can only attempt to address it when I have time, and I can only commit to finding some time within the next month. It would be even better if you could complete it in advance through a PR. Honestly, I would prefer to reimplement this library in Rust, but maintaining the language server has consumed all my spare time.

CppCXY avatar Mar 02 '25 17:03 CppCXY

Yeah, don't worry, I understand you perfectly, and people may be busy with something else, or just lose interest. It is ok.

This is just a my small sadness, as an emoji. I don't have time to help you with this project either... maybe if I really need to, but for now I'm happy with everything.

TIMONz1535 avatar Mar 02 '25 19:03 TIMONz1535