Dawid Weiss

Nice! So... google java format has this option, at least in the cmd line version:  If nothing else works, we could just make a multipass and format javadocs using...

https://github.com/google/google-java-format/issues/1193 > Disabling Javadoc formatting doesn't prevent either issue. So it seems it's broken entirely. Argh.

> I just think autoformat the code in a consistent way, call it a day. I agree, it does not matter which one you pick if it's an automated process....

We'd probably have to apply reformatting to 10x and main to keep cherry picking easier. Other than that - it's a simple thing to do.

I've toyed with it a bit but I don't see a way for it to not break those /// comments. An alternative is to fork it, fix what we need...

https://github.com/google/google-java-format/blob/master/core/src/main/java/com/google/googlejavaformat/java/JavaCommentsHelper.java#L46-L60 All it takes would be to preserve any formatting in markdown comments (the /// lines) - a dumb check above would do the trick, I think.

Yeah. I'll take a look at that, interesting. Part of the problem is that different Java versions seem to be returning a different tokenization of those comment strings. Seems like...

Yes, that's correct - https://github.com/google/google-java-format/issues/1153#issuecomment-2344790653

Here is what I did. * added a brute-force non-formatting to any /// line comments in my fork of google-java-format [1] * added a local, precompiled binary of the above...

It'll work with those indented lines as well - it actually will align block indentation to the column they should be starting at. So: ``` /// [Collector] for cutter+recorder pair....