Have a bunch of Kotlin code that was previously fo...

# ktlint

[Chris Lee]

Have a bunch of Kotlin code that was previously formatted “incorrectly” (differently) wrt wrapping; haven’t been able to get either IntelliJ or ktlint to correct this, without manually editing these (when I find them and feel like investing the time to correct it).
It seems like ktlint is attempting to preserve existing wrapping; would be nice to throw all that away and reapply the current rules (which may be different from previous rules).
Sample code (one case; in general, this applies to all manner of wrapping - extends/implements, args, etc):

val sourceProperty =
    environment.getProperty(
        pair.first,
    )

(removing the trailing , doesn’t change this.

ktlint 0.50.0, with this in `.editorconfig`:

[*.{kts,kt}]
indent_size = 4
max_line_length = 200

ktlint_code_style = ktlint_official
ktlint_standard_max-line-length = disabled
ktlint_standard_property-naming = disabled
ktlint_experimental=enabled

ij_kotlin_packages_to_use_import_on_demand = java.util.*
ij_kotlin_name_count_to_use_star_import = 2147483647
ij_kotlin_name_count_to_use_star_import_for_members = 2147483647

In IntelliJ can partially address this by turning off `Keep when reformatting -> Line breaks`; result:

val sourceProperty = environment.getProperty(
                pair.first,
            )

(goal would be for this all to be on one line as it shouldn’t wrap)
Possible to achieve this with ktlint? If not, happy to help with a PR for this.

[Paul Dingemans]

Hi Chris,

Ktlint has no functionality for this. I do not think that a rule should be added that removes newlines generically as this might cause conflicts with the wrapping rule.

What can be done, is that you create a new rule that rewrites a construction like a function call as in your example. The difference is that such a rule completely rewrites a function call and inserts newlines when the function call does not fit a line or removes newlines when the call can fit a single line. You can take a look at the function-signature and the new yet unreleased class-signature to get an idea how this can be done. In your example above, this would mean, that you will only rewrite following:

getProperty(
                pair.first,
            )

Reason for this, is that the . expression will be rewritten by yet another rule (in progress).

It can be challenging (but very satisfying) to write a rule like this. I strongly encourage a TDD approach and test only 1 thing in a single test. Please submit a PR in an early stage so that I can help/review you before you spend too much time on it.

[Chris Lee]

Thanks. My overarching thinking was that a formatter should start with a normalized AST - removing all non-required tokens (preserving what is needed, such as comments) and then print the code from there.
That doesn’t appear to be how ktlint works - will have a look at creating a rule.

[Paul Dingemans]

No that is definitely not how ktlint works at this moment. But I am moving ktlint more and more towards such model. The rules that I mentioned are examples of this. But it will take a lot of work to complete this.

[Chris Lee]

interesting. happy to help with that. will have a look at the code to get familiar with it.