Problem
Found while linting pslua-generated Lua in a downstream application (OpenResty, with luacheck and lua-language-server). Cosmetic only: the code runs and passes luac -p. Re-confirmed on current main.
Line length is unbounded: the Golden.LongBindFlipped output has a single line of 3149 characters. The printer optimises for correctness (luac -p), not width, so long call chains and table literals print on one line. Downstream luacheck run with --max-line-length 130 (the value the ecosystem's own FFI CIs use) flags them.
Approach
If in scope, add a width-aware break for long call chains and table literals.
Prerequisites / Relations
None.
Verification / Measurement
luacheck with --max-line-length 130 passes on the golden outputs.
Open questions
Whether this is in scope at all: consumers can raise --max-line-length, so it may be wontfix by design. Lowest priority.
Problem
Found while linting pslua-generated Lua in a downstream application (OpenResty, with luacheck and lua-language-server). Cosmetic only: the code runs and passes
luac -p. Re-confirmed on currentmain.Line length is unbounded: the
Golden.LongBindFlippedoutput has a single line of 3149 characters. The printer optimises for correctness (luac -p), not width, so long call chains and table literals print on one line. Downstream luacheck run with--max-line-length 130(the value the ecosystem's own FFI CIs use) flags them.Approach
If in scope, add a width-aware break for long call chains and table literals.
Prerequisites / Relations
None.
Verification / Measurement
luacheck with
--max-line-length 130passes on the golden outputs.Open questions
Whether this is in scope at all: consumers can raise
--max-line-length, so it may be wontfix by design. Lowest priority.