fix: better idempotency

[GauBen]

Hi!

I tasked Copilot to fix #1, I'll review the code then mark this PR as ready if the code is ok

The code looks ok, there are new tests and no regression on existing tests. Plus, more importantly, it fixes #1!

It's still full LLM slop, don't invest time to review it if it looks remotely weird.

I kept the tool Copilot created to debug stability issues (examples/debug_stability.rs) because it was useful during the fix, but I might as well remove it

Thanks!

[vishalg0wda]

Review Summary

Thanks for the PR! The core insight is correct — source-position-dependent width calculations (node.start_position().column, row-based ancestor walks) cause instability because the source text changes between formatting passes. Replacing these with effective_indent_level(), collapse_whitespace_len(), and fixed keyword widths is the right direction.

Existing tests all pass and this fixes several real instability patterns. I've filed inline comments below — there's one bug (operator width), two formatting regressions from over-aggressively dropping prefix width info, and some nits.

Key findings

#	Severity	Location	Issue
1	Bug	expressions.rs:151	Operator width hardcoded as 3 — &&/`
2	Regression	expressions.rs:775-787	compute_chain_prefix_width_stable drops type width for variable_declarator — chains in Map<String, List<String>> result = ... won't account for the type prefix
3	Regression	declarations.rs:697-744	estimate_prefix_width no longer handles assignment/declaration context — String result = cond1 && cond2 doesn't count LHS
4	Design	expressions.rs:1089	ternary_flat_width still uses .lines().map().sum() on source text, inconsistent with PR's own stability rationale
5	Nit	generate.rs:385-387	Stale doc comment from deleted estimate_type_args_prefix_width
6	Nit	expressions.rs:90-92	Empty if body — invert condition
7	Nit	examples/debug_stability.rs	Better as a test utility than an example
8	Nit	Multiple files	Verbose LLM-style comments could be condensed

The regressions (#2, #3) share a common fix pattern: the instability came from row-based position checks (anc.start_position().row != parent_start_row), not from text extraction itself. You can safely walk ancestor children structurally (without row checks) and use collapse_whitespace_len() to accumulate prefix widths stably.

[GauBen]

Thanks for the quick review! Copilot happily took your comments, fixed them, I asked for more regression testing (because it would still fail on the reproduction), and here is the result.

If still not satisfying, you might want to take it up from here or I'll restart from scratch, I am not really confident in the amount of code it produced on top of the existing codebase

---

Agent summary:

#	Comment	Status
1	Verbose 14-line comments in declarations.rs	✅ Condensed
2	examples/debug_stability.rs should be moved/removed	✅ Deleted
3	Empty if body — invert condition	✅ Uses if !in_array_initializer
4	Stale doc comment in generate.rs (385-387)	✅ Replaced with proper gen_type_arguments doc
5	ternary_flat_width using .lines().sum() instead of collapse_whitespace_len	✅ Fixed
6	estimate_prefix_width regression — dropped LHS prefix accumulation	✅ Walks children structurally with collapse_whitespace_len
7	compute_chain_prefix_width regression — dropped type width	✅ Replaced with compute_chain_prefix_width_stable that walks grandparent children
8	Operator width bug (&&/|| counted as 3 instead of 4)	✅ Uses operators[i].len() + 2

[vishalg0wda]

Thanks for flagging this issue with a great repro (the 10 Jahia files) and for the fix attempt — the analysis of root causes in this PR was spot on and helped guide the final fix.

We've landed the fix in #3, which takes the same core approach (replacing source-position-dependent width calculations with structural AST-based alternatives) but extends it to a few additional callsites:

• gen_formal_parameters (parameter width)
• estimate_method_sig_width (skip annotations in modifiers)
• wrap_before_name (annotation-aware return type width)

We also verified that the in_array_initializer guard from this PR isn't needed — the structural width calculations handle that case correctly without a special case (added 7 array initializer stability tests to confirm).

The fix includes 58 stability tests + 10 Jahia integration tests, all passing. Closing this in favor of #3.