TabsAndIndents (java): indent-normalisation trips over mixed indents.

[juleskers]

Hi, and thank you for making this tool!
It's great to see dependable, deterministic machinery in this age of "just LLM it, bro".
I have much more trust in machine-transformations than vague, expensive GPU magic.

---

I'm exploring OpenRewrite to get a handle on a large-ish (80k lines) java/maven multimodule project.

As a toy example / getting my feet wet, I'm normalising the (partially cursed) mixed indents spread in the ancient parts.
The ancient parts mix tabs, spaces, tabs-then-spaces, spaces-then-tabs and most cursed of all: spaces-tab-spaces-tab, depending on which author copy-pasted which snippet in which IDE (through several copy-paste iterations).

I've standardised the three current devs on .editorconfig, choosing tab-indents, stopping future madness.

• (I saw related Pick TabsAndIndentsStyle from .editorconfig #3666, though I don't think it affects this situation).

Applying the org.openrewrite.java.format.NormalizeTabsOrSpaces recipe gets me most of the way there.
However: a few of the cursed situations are mishandled, resulting in lost indent-levels and weird-looking code.

I didn't apply any configuration to the recipe, so I'm unsure if autodetection got it right, or if a config somewhere got picked up.
"normal" 4-space indented files got handled without a hitch, so whatever the source, the style matches what I want.

What version of OpenRewrite are you using?

I am using

• Maven plugin 6.38.0
• OpenRewrite v??
• rewrite-java v??

How are you running OpenRewrite?

I am using the Maven plugin, and my project is a multi module project.
The config is applied only in the project-parent, delegating most of the actual config to a top-level rewrite.yml.

<!-- in multi-module parent; nothing in child modules -->
<plugin>
	<groupId>org.openrewrite.maven</groupId>
	<artifactId>rewrite-maven-plugin</artifactId>
	<version>6.38.0</version>
	<configuration>
		<exportDatatables>false</exportDatatables>
		<activeRecipes>
			<recipe>com.example.whitespace-pedantry</recipe>
		</activeRecipes>
	</configuration>
</plugin>

# project-root/rewrite.yml
---
type: specs.openrewrite.org/v1beta/recipe
name: com.example.whitespace-pedantry
recipeList:
  - org.openrewrite.java.format.RemoveTrailingWhitespace
  - org.openrewrite.java.format.NormalizeTabsOrSpaces
  - org.openrewrite.java.format.EmptyNewlineAtEndOfFile

What is the smallest, simplest way to reproduce the problem?

The clearest example I could find was 'normal' tab-indentation
except for the first column (which used 4-spaces instead of tab).

I've created the following example class to demonstrate all issues I found (And some additional natural variations).
Including this in a random position in my codebase gets the same mis-indenting applied as the real code.

I'm not sure how to get the github code view to show whitespace, but copy-pasting it into a full editor should reveal the cursed-ness. (or drag-selecting in the indents; note the jumps)

For reference, this is intended to be tabwidth=4. (though the form-entry field seems to use tab=8)
It mixes all permutations of spaces, tabs, tab-then-spaces, spaces-then-tabs as well as spaces-tab-spaces, tabs-spaces-tabs and even tab-spaces-tab-space and spaces-tab-spaces-tab.
You'd think this overkill, but I did actually have a real spaces-tab-spaces-tab case in the code-base.

(Don't get me started on the """text-blocks"""... Those are equally cursed, but correctly untouched by this recipe)

public class CursedIndents {
	public void iStartWithAllTabs() {
		System.out.println("\t is cool");
		if (true) {
			System.out.println("3 tabs are cooler");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

    public void iStartWithAllSpaces() {
        System.out.println("space is cool");
        if (true) {
            System.out.println("12 spaces are cooler");
            if (false) {
                System.out.println("nesting-ception");
            }
        }
    }

	public void tabsThenSpaces() {
	    System.out.println("mixing is cool");
	    if (true) {
	        System.out.println("more spaces is more cool");
	        if (false) {
	            System.out.println("nesting-ception");
	        }
	    }
	}

    public void spacesThenTabs() {
    	System.out.println("\t is cool");
    	if (true) {
    		System.out.println("3 tabs are cooler");
    		if (false) {
    			System.out.println("nesting-ception");
    		}
    	}
    }

	public void trulyCursed() {
    	System.out.println("\t is cool");
	    if (true) {
	    	System.out.println("the mixing, it pains me.");
    	    if (false) {
	    	    System.out.println("multi-mixing, tabs-first");
    	    	System.out.println("multi-mixing, spaces-first");
			}
    	}
	}
}

What did you expect to see?

I had hoped all 4-spaces would become 1 tab, regardless of their position in the cursed mix.
As in: Scoping the replacement to the entire leading whitespace-mix, replacing all occurrences.
Instead multiple "boundaries" seem to mess up the result.

public class NoLongerCursedIndents {
	public void iStartWithAllTabs() {
		System.out.println("\t is cool");
		if (true) {
			System.out.println("3 tabs are cooler");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

	public void iStartWithAllSpaces() {
		System.out.println("space is cool");
		if (true) {
			System.out.println("12 spaces are cooler");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

	public void tabsThenSpaces() {
		System.out.println("mixing is cool");
		if (true) {
			System.out.println("more spaces is more cool");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

	public void spacesThenTabs() {
		System.out.println("\t is cool");
		if (true) {
			System.out.println("3 tabs are cooler");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

	public void trulyCursed() {
		System.out.println("\t is cool");
		if (true) {
			System.out.println("the mixing, it pains me.");
			if (false) {
				System.out.println("multi-mixing, tabs-first");
				System.out.println("multi-mixing, spaces-first");
			}
		}
	}
}

What did you see instead?

• ✔️ 4-spaces gets turned into 1-tab
  • other classes with 8-spaces, 12-spaces, 16-spaces correctly turn into 2/3/4 tabs.
• 💣 4-spaces, then-tab, then code/end-of-whitespace becomes one tab (rather than two, as expected)
  in effect, "eating" the 4-spaces without replacing them with anything? (or replacing the four spaces, but eating the original tab?)
• 💣 4-spaces, then-tab, then more tabs becomes "more tabs".
  in effect, losing two indent-levels (3->1, 4->2)

public class CursedIndents {
	public void iStartWithAllTabs() {
		System.out.println("\t is cool");
		if (true) {
			System.out.println("3 tabs are cooler");
			if (false) {
				System.out.println("nesting-ception");
			}
		}
	}

	public void iStartWithAllSpaces() {
		System.out.println("space is cool");
		if (true) {
			System.out.println("12 spaces are cooler");
			if (false) {
					System.out.println("nesting-ception");
			}
		}
	}

	public void tabsThenSpaces() {
		System.out.println("mixing is cool");
		if (true) {
			System.out.println("more spaces is more cool");
			if (false) {
					System.out.println("nesting-ception");
			}
		}
	}

	public void spacesThenTabs() {
	System.out.println("\t is cool");
	if (true) {
	System.out.println("3 tabs are cooler");
	if (false) {
		System.out.println("nesting-ception");
	}
	}
	}

	public void trulyCursed() {
	System.out.println("\t is cool");
		if (true) {
		System.out.println("the mixing, it pains me.");
		if (false) {
				System.out.println("multi-mixing, tabs-first");
			System.out.println("multi-mixing, spaces-first");
			}
	}
	}
}

What is the full stack trace of any errors you encountered?

No errors reported by this recipe, even when running with --errors

Are you interested in contributing a fix to OpenRewrite?

I like paying it forward, but am daunted by the IDE setup requirements.
"just ./gradlw build" didn't cut it, IntelliJ can't figure it out either.
I don't plan on setting up multiple JDKs on my work machine just for this.

I've tried making a test-case out of this to open as PR, but gave up battling gradlew after half an hour of it complaining it can't find the proper java-8 on my machine. Blocking modules in ide.properties lead to missing dependency-errors, in gradle build scripts, and I didn't summon the energy to reverse-engineer the module dependency network.
(which quickly lead back to gradle complaining I have no java-8)

I hope this minimal reproducer can be easily copy-pasted by someone with a functioning IDE setup.
I'll gladly review code, brainstorm fixes and engage in other ways that don't require a working IDE.

[juleskers]

P.S. I am certain the answer is in https://github.com/openrewrite/rewrite/blob/main/rewrite-java/src/main/java/org/openrewrite/java/format/NormalizeTabsOrSpacesVisitor.java#L97
But my yak-shaving contingent for today is exhausted.

[Jenson3210]

Hi, Thanks for the report.

To get an insight of your style which is detected, you can run Find Styles. The exported data table will print for every file what style is linked to that source (hence will also print the auto-detected java style. That might explain why certain indentations break.

However, as a general note these recipes you're referring to are typically not run in isolation.
These are parts of the bigger AutoFormat recipe which runs them in an order that causes the indentation to be correctly re-added if lost as part of an earlier visitor.

rewrite/rewrite-java/src/main/java/org/openrewrite/java/format/AutoFormatVisitor.java

Lines 56 to 77 in 43b2ad0

	JavaSourceFile cu = (tree instanceof JavaSourceFile) ? (JavaSourceFile) tree : cursor.firstEnclosingOrThrow(JavaSourceFile.class);
	if (tree == null) {
	tree = cursor.getValue();
	}
	List<NamedStyles> activeStyles = new ArrayList<>(cu.getMarkers().findAll(NamedStyles.class));
	activeStyles.addAll(styles);
	// Format the tree in multiple passes to visitors that "enlarge" the space (Eg. first spaces, then wrapping, then indents...)
	J t = new NormalizeFormatVisitor<>(stopAfter).visitNonNull(tree, p, cursor.fork());
	t = new MinimumViableSpacingVisitor<>(stopAfter).visitNonNull(t, p, cursor.fork());
	t = new SpacesVisitor<>(activeStyles, stopAfter).visitNonNull(t, p, cursor.fork());
	t = new WrappingAndBracesVisitor<>(activeStyles, stopAfter).visitNonNull(t, p, cursor.fork());
	t = new NormalizeTabsOrSpacesVisitor<>(activeStyles, stopAfter).visitNonNull(t, p, cursor.fork());
	t = new TabsAndIndentsVisitor<>(activeStyles, stopAfter).visitNonNull(t, p, cursor.fork());
	// With the updated tree, overwrite the original space with the newly computed space
	tree = new MergeSpacesVisitor(activeStyles).visitNonNull(tree, t, cursor.fork());
	// Then apply formatting that applies on line-endings / #lines / ...
	tree = new BlankLinesVisitor<>(activeStyles, stopAfter).visitNonNull(tree, p, cursor.fork());
	tree = new NormalizeLineBreaksVisitor<>(activeStyles, cu, stopAfter).visitNonNull(tree, p, cursor.fork());
	tree = new RemoveTrailingWhitespaceVisitor<>(stopAfter).visitNonNull(tree, p, cursor.fork());

shows this behavior.

If we can figure out the style yaml that works for your use case, calling autoformat should be possible causing these java files to all start using the correct formatting.

[juleskers]

👋 Goedemorgen @Jenson3210

Sorry for being slow to react, I had holidays and a big project milestone compete for my time.

---

Thanks for clarifying that not all of these recipes are designed for standalone usage.
That makes sense, although it was completely unclear to me.

(background: my entrypoint is browsing the Recipes Catalog. That does show if a recipe is used in other recipes, but gives no indication that some recipes are intended only in combination/aggregation)

I do think that, even despite the intended use-case, this indent-recipe could be made stand-alone capable.
It seems it almost always does the right thing, which gives me hope the algorithm can be fixed to be generally applicable.

Is that something you would consider worth pursuing?

---

I don't think we'll easily arrive at a full autoformat specification to run the whole autoformatter.

My team is mixed eclipse, IntelliJ, VsCode users, so "the" style doesn't exist.
I tried standardising the import order once. Didn't go down well.. (IntelliJ and Eclipse have opposite defaults)
At least the VSCode and IntelliJ now both obey the .editorconfig for some parts.

As the GoLang-people say, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
Since no such default exists in Java, some people don't even feel like "haggling over pointless formatting details" (or format tooling) is worth time at all.
(I've tried pointing out that it will make tooling-applied refactorings easier to work with, no dice)..

And that's without considering that the full autoformat diff will be completely unreviewable.

So yeah, I'm trying to work my way forward in tiny, incremental steps.

---

I've gotten around to running FindStyles on the codebase.

I think the relevant section from org.openrewrite.table.StylesInUse.csv are these bits?
(header and general autodetect, and scrolled waaaaay down to the the specific cursed file)

# @name org.openrewrite.table.StylesInUse
# @instanceName Styles in use
# @group 
sourcePath,styleNames,stylesYaml
pom.xml,org.openrewrite.xml.Autodetect,"---
type: specs.openrewrite.org/v1beta/style
name: org.openrewrite.xml.Autodetect
displayName: Auto-detected
styleConfigs:
- org.openrewrite.xml.style.TabsAndIndentsStyle:
    continuationIndentSize: 1
    indentSize: 1
    tabSize: 1
    useTabCharacter: true
- org.openrewrite.style.GeneralFormatStyle:
    useCRLFNewLines: false"
...

<SNIP>/src/main/java/de/<SNIP>.java,"org.openrewrite.java.Checkstyle, org.openrewrite.java.Autodetect","---
type: specs.openrewrite.org/v1beta/style
name: MergedStyles
displayName: Merged styles
styleConfigs:
.....
- org.openrewrite.java.style.TabsAndIndentsStyle:
    continuationIndent: 8
    indentSize: 4
    indentsRelativeToExpressionStart: false
    tabSize: 4
    useTabCharacter: true

I'm attaching the (filenames-redacted) copy of the full output. You can probably glean more from it than I can.
StylesInUse.csv

It looks like all the java files receive this same autodetection for TabsAndIndentStyle: the exact block occurs 394 times in my file, which matches the count of java source-files in the detection output.
However, find . -name *.java | wc says I have 798 java files (19 XML)

Is it good or bad that it detects almost 400 styles?

[Jenson3210]

and scrolled waaaaay down to the the specific cursed file
...
Is it good or bad that it detects almost 400 styles?

Love the usage of the amount of a's here 🤣
This recipe is indeed for troubleshooting / insights, but a biiiiig datatable can come out of it!
The goal of the recipe is to list all style markers.
Whenever a lst is built, style detection runs over all files and identifies what style is globally used acros the entire project.
This one detected resulting style is then attached to all files. This is required so that a java recipe changing a single file does not have to look up other files that declare the style and to be able to get a consistent style for al java files (yaml files for example can have a different style per file if not mistaken as they do not calculate the style per repo but per file). So basically, yes we would expect in a normal project to have a uniform style marker on every java file.
Some people might have played with the style for certain paths (eg, by running Format recipe with a precondition selecting only the files matching a pattern) in the repo and that is why we put the attached marker per file in the datatable. This explains that you find a marker on every file that should be the same on every file in your case. (for the java ones at least, not the yaml ones per se...)

TL;DR:
yes you can expect the same style result in this datatable on all java files in a default project setup/recipe run. This is so that a recipe itself which visits file by file has all necessary information for its own formatting without the external dependencies during the visiting phases.

Merging multiple configured styles

That being explained, I verified all your 394 java styles are Merged styles that come out as a result from merging Checkstyle style with autodetected style. Did you enable Checkstyle when running? Or is this also by default attached (not sure and would have to dig deeper if you did not select this one as active one).
What does merging mean: multiple styles can be set, the first one that sets a property wins.
eg.

SomeStyle:
  nested:
    property1: true
    property2: 1
  property3: true
  property4: 1
---
SomeOtherStyle:
  nested:
    property1: false
    property5: 2
  property3: false
  property6: 2

would merge:

MergedStyle:
  nested:
    property1: true
    property2: 1
    property5: false
  property2: true
  property4: 1
  property6: 2

This style would then be active for all changes.

What may be the solution here

Now... That's a very long explanation about styles whereas you might just hope for a fix here.
This "multiple teams not being able to agree upon a style" is quite common.
That's why we allow to call AutoFormat with partial styles after which the autodetected style will take over those properties not mentioned in the first style. (see merging)

In your case, it's possible that calling AutoFormat with only the properties you want to overwrite might give you the result you are hoping for:

type: specs.openrewrite.org/v1beta/style
name: org.openrewrite.java.PriorityStyle
displayName: My custom style takes priority
styleConfigs:
- org.openrewrite.java.style.TabsAndIndentsStyle:
    continuationIndent: 8
    indentSize: 4
    indentsRelativeToExpressionStart: false
    tabSize: 4
    useTabCharacter: true

as using this style will make your Java classes use org.openrewrite.java.PriorityStyle to identify the properties mentioned and then augment that one during the merging with autodetected styles.
Teams that use import order A will keep import order A, whereas teams that have import order B keep B. Another advantage would be that import orders scrambled throughout a codebase would also become uniform accros that project based on the autodetected style.

Disclaimer: This Autodetection is best effort and for some properties there is still IntelliJ defaults being applied when no style is detected to make sure that no style property is ever null/blank/unset.

In the meantime, I can also see if I can find the correct combination of recipes that would yield your expected result on my end. For example, I am missing the TabsAndIndents here that might already readd the correct indentations to your provided snippet (using the correct indentation character based on the style markers attached)

[Jenson3210]

Hi @juleskers,

I had a closer look — the symptom is exactly what you suspected: NormalizeTabsOrSpaces running in isolation strips your leading 4-space chunks but never re-computes the indent depth, so any line that started with a "spaces-then-tab" prefix loses indent levels. In AutoFormatVisitor this is intentionally compensated for by running TabsAndIndents immediately afterwards (see AutoFormatVisitor.java#L64-L77).

Since you said you only want to touch indentation/newlines (no imports, no full AutoFormat), the smallest change to your rewrite.yml is to insert TabsAndIndents right after NormalizeTabsOrSpaces:

type: specs.openrewrite.org/v1beta/recipe
name: com.example.whitespace-pedantry
recipeList:
  - org.openrewrite.java.format.RemoveTrailingWhitespace
  - org.openrewrite.java.format.NormalizeTabsOrSpaces
  - org.openrewrite.java.format.TabsAndIndents          # <-- add me
  - org.openrewrite.java.format.EmptyNewlineAtEndOfFile

TabsAndIndents only adjusts the prefix whitespace of LST nodes — it does not touch imports, blank lines, spaces around operators, or anything else. It honors the same TabsAndIndentsStyle that NormalizeTabsOrSpaces already reads, so the active style you shared (useTabCharacter: true, tabSize: 4, indentSize: 4, continuationIndent: 8) will Just Work.

To make sure this actually fixes your CursedIndents reproducer (no intention of making a PR from this), I pushed a branch with two tests against your exact fixtures:

• Branch: Jenson3210/autoformat-indent-only-test

• Diff: AutoFormatTest.java

  • normalizeTabsOrSpacesAloneDropsIndentationLevels — your current YAML, asserts the broken output you reported.
  • addingTabsAndIndentsRestoresCorrectIndentation — same YAML + TabsAndIndents, asserts the expected output.

Both tests pin your TabsAndIndentsStyle explicitly so the result doesn't depend on Autodetect.

Could you try this workaround on your codebase and let us know if it resolves the symptoms? If it does, I'll close out the issue and delete the branch. If anything's still off, leave a note here — happy to iterate.

(The remaining longer-term question — should NormalizeTabsOrSpaces be safe to run standalone? — I'd treat as a separate discussion; the visitor is intentionally a fragment of AutoFormat's pipeline today, but the docs catalog doesn't make that obvious, which is a fair point.)

[juleskers]

Thanks for the detailed analysis! I would have never gotten that far!

Good news first: Adding TabsAndIndents indeed solves the issue 🎉

The 'real' files that exhibited the problem are fixed, and the CursedIndents-canary I left in the codebase also looks good!.

I do notice a bunch of extra tab-indent fixes scattered around the codebase. Seems I have been misinterpreting the 'correct' depth for continuation-blocks in several cases.

As for the many sub-points:

• CheckStyle: The departmental parent-pom, which my project inherits from has maven-checkstyle-plugin in its <build><plugins>.. block.
  My assumption is that this is sufficient to enable the style?

  • I did not explicitly enable checkstyle, I did a 'dumb' mvn rewrite:run with the exact config from the opening comment, and now again with the same configs with your suggested modification (included below for completeness' sake).

• CursedIndents reproducer (no intention of making a PR from this)

  Would you like me to make a PR of it? I'm not sure if the whitespace-only testcase is worth anything to the project as a whole, or if that is already indirectly covered by larger autoformatter-tests. However, it seems a shame to throw a way such a targeted test of indenting-behaviour. (at the very least, addingTabsAndIndentsRestoresCorrectIndentation encodes the intended pairing.

• longer-term question — should NormalizeTabsOrSpaces be safe to run standalone?

  I'm torn. Looking at the source-code, I looks like it should work, but we see it sometimes misses the boat.
  That means there's probably some off-by-one error, or edge-case hidden in there that I'd need to sit down for with a debugger and a minimal reproducer.
  I could do that, but it'll likely be a while (days? weeks? months?) before I can make the time for it.
  My suspicion is that something about the spaces-counting (j < style.getTabSize()) is off when it starts at consecutiveSpace==0, so it triggers continue outer instead of emitting the tab. Those are the worst kinds of subtlety to figure out 😬

  rewrite/rewrite-java/src/main/java/org/openrewrite/java/format/NormalizeTabsOrSpacesVisitor.java

  Lines 112 to 121 in 7d86732

  	} else if (style.getUseTabCharacter() && c == ' ' && (!isComment ||
  	(i + 1 < text.length() && text.charAt(i + 1) != '*'))) {
  	int j = i + 1;
  	for (; j < text.length() && j < style.getTabSize(); j++) {
  	if (text.charAt(j) != ' ') {
  	continue outer;
  	}
  	}
  	i = j + 1;
  	textBuilder.append('\t');

  This is made worse by the fact I haven't got my IDE set up. Installing + configuring all the required java-runtimes are a hurdle I don't feel like conquering for such a small improvement.

• the docs catalog doesn't make [the fact that some recipes are cooperative fragments] obvious, which is a fair point.

  Now that is something I think I can help with in a foreseeable timeframe. I found https://github.com/openrewrite/rewrite-docs/tree/master/docs/recipes/java/format and will see if I can make a contribution there.

  From my cursory inspection, this "bunch of cooperative fragments" seems to be mostly contained to the java-formatter.
  (writing this down for posterity / future self)

  • The same pattern doesn't immediately jump out to me in Kotlin or Groovy, though that may be because I'm not digging deep enough.
  • I see echoes of it in HCL.
  • Cobol, C#, Python, Scala don't seem to have a formatter(?), so the problem is moot.
  • XML has the same 'normalize + indent' sub-recipes.
  • I'm sorry, I'm not going anywhere near the JavaScript formatter, which has a gazillion formats, another gazillion of cleanups but no obvious "put it all together" entrypoint? (Unless it's Recommended ESLint Styling?)

---

updated rewrite.yml with Jenson3210 suggestions

---
type: specs.openrewrite.org/v1beta/style
name: com.example.indentingStyle
displayName: My custom tab-indenting style (takes priority over autodetect)
styleConfigs:
  - org.openrewrite.java.style.TabsAndIndentsStyle:
      continuationIndent: 8
      indentSize: 4
      indentsRelativeToExpressionStart: false
      tabSize: 4
      useTabCharacter: true
---
type: specs.openrewrite.org/v1beta/recipe
name: com.example.whitespace-pedantry
recipeList:
  # Many tools work better if all lines, including the final one, have trailing newlines
  # SonarQube RSPEC-S113: https://next.sonarqube.com/sonarqube/coding_rules?languages=java&q=S113&open=java%3AS113
  - org.openrewrite.java.format.RemoveTrailingWhitespace
  # Two-stage re-indent: first stage removes non-matching indents, second stage re-indents everything to correct depth.
  - org.openrewrite.java.format.NormalizeTabsOrSpaces
  - org.openrewrite.java.format.TabsAndIndents
  # Run this last, as it cannot work on the AST-level, so 'downgrades' all internal structures to flat text.
  - org.openrewrite.java.format.EmptyNewlineAtEndOfFile

[Jenson3210]

Seems I have been misinterpreting the 'correct' depth for continuation-blocks in several cases.

IntelliJ also in some occasions surprised me when I "recently" added a bunch of coverage for the intelliJ code style properties.

I did a 'dumb' mvn rewrite:run with the exact config from the opening comment,

Then indeed probably we pick up that plugin/configuration. I am not too deeply familiar with the style detection.

However, it seems a shame to throw a way such a targeted test of indenting-behaviour.

Mostly coded by sending a correct prompt to claude. We have various unit tests that cover these components by itself and then also a lot of tests that verify exactly this behavior from the AutoFormat recipe. If we have to start adding unit tests for every possible combinations of recipes, that would just be a disaster for our CI pipeline duration 😉 I am fine with throwing this out. No affection towards the unit test generated.

I looks like it should work, but we see it sometimes misses the boat.

I think a unit test (I can make that if you have a repro) might be good to debug but will probably not get around to this anywhere soon.

This is made worse by the fact I haven't got my IDE set up. Installing + configuring all the required java-runtimes are a hurdle I don't feel like conquering for such a small improvement.

Totally understandable! We can look at setting up your environment if you are interested in that. But if you're not planning on contributing anything anywhere soon, that's not necessary I assume.

Now that is something I think I can help with in a foreseeable timeframe. I found https://github.com/openrewrite/rewrite-docs/tree/master/docs/recipes/java/format and will see if I can make a contribution there.

Important to realize here is that docs are generated from the code. Title / description are both fields present in the recipes code. This gets scraped and created the catalog. So there's not a lot of value in a PR on rewrite-docs when the slug of the docs contains /recipes/ part. If you want to update the docs, You should in fact update the description field in these impacted recipe's codebase.

The same pattern doesn't immediately jump out to me in Kotlin or Groovy, though that may be because I'm not digging deep enough.

The same pattern is used in other languages. The recipe itself calls the AutoFormatVisitor which in turn delegates to these other recipes. Same thing applies for Groovy, scala, XML, JSON...

Your links to Javascript are referring to our codemods support. This is no longer used for real javascript support. We use rewrite-javascript where recipes run a bit different. Javascript recipes will run in Javascript environment so the code for that is also in ts. But the concept of visiting through these visitors is the same.
Same concept for python. These recipes run in python env, are coded in python BUT use the same concept

For C# we delegate this to Roslyn, so that is the odd one atm.
https://github.com/openrewrite/rewrite/blob/main/rewrite-csharp/csharp/OpenRewrite/CSharp/Format/AutoFormatVisitor.cs

Having mentioned this, we had considered refactoring these Recipes to be only Visitors (hence cannot be called directly through yaml), but that was decided against as we might break people already calling them. In general, when we create components that should not be run in isolation, we would create (internal) visitor classes preferably so someone who really wants to run that by itself has to wrap a Recipe around it. But we cannot do that here/now due to backwards compatibility.