Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ktlint-cli --code-style=intellij_idea is not respected in ktlint 1.0.0 #2238

Closed
voegelas opened this issue Sep 5, 2023 · 3 comments · Fixed by #2241
Closed

Ktlint-cli --code-style=intellij_idea is not respected in ktlint 1.0.0 #2238

voegelas opened this issue Sep 5, 2023 · 3 comments · Fixed by #2241
Milestone

Comments

@voegelas
Copy link

voegelas commented Sep 5, 2023

Expected Behavior

In the following example, ktlint should not complain about "multiline-expression-wrapping" if the code style is set to "intellij_idea".

val chars = "foo".map { c ->
    c
}

Observed Behavior

ktlint 1.0.0 outputs a "multiline-expression-wrapping" warning and inserts a newline and an extra indentation level if the code is formatted. Intellij IDEA doesn't do that and puts the lambda expression back on the first line if the code is formatted twice. ktlint 0.50.0 works as expected.

val chars =
    "foo".map { c ->
        c
    }

Steps to Reproduce

Run ktlint --code-style=intellij_idea example.kts on the first example.

Your Environment

  • Version of ktlint used: 1.0.0
  • Operating System and version: Fedora 38 with OpenJDK 17 and Kotlin 1.9.0
@voegelas voegelas changed the title Assignment with lambda expression on the same line cause multiline-expression-wrapping warning Assignment with lambda expression on the same line causes multiline-expression-wrapping warning Sep 5, 2023
@paul-dingemans
Copy link
Collaborator

Property --code-style=intellij_idea is indeed not passed correctly to ktlint rule engine. Also in previous versions this was not done correctly but in those releases the default codestyle was intellij_idea.

When you specify the code style in the .editorconfig file, it is respected though. This is also the preferred way to specify the code style as it will then be used by everyone working on the same project (provided that the .editorconfig is committed to the repository).

root = true

[*.{kt,kts}]
ktlint_code_style = intellij_idea

@paul-dingemans paul-dingemans added this to the 1.0.1 milestone Sep 5, 2023
@paul-dingemans paul-dingemans changed the title Assignment with lambda expression on the same line causes multiline-expression-wrapping warning Ktlint-cli --code-style=intellij_idea is not respected Sep 5, 2023
@paul-dingemans paul-dingemans changed the title Ktlint-cli --code-style=intellij_idea is not respected Ktlint-cli --code-style=intellij_idea is not respected in ktlint 1.0.0 Sep 5, 2023
@paul-dingemans paul-dingemans pinned this issue Sep 5, 2023
paul-dingemans added a commit that referenced this issue Sep 5, 2023
@paul-dingemans paul-dingemans linked a pull request Sep 5, 2023 that will close this issue
9 tasks
@voegelas
Copy link
Author

voegelas commented Sep 5, 2023

I think that it's useful to be able to pass the code style on the command line. I've started to use Kotlin for scripting too. Adding an .editorconfig file to each and every script and repository is cumbersome. I've got the following settings in my Vim configuration:

let b:ale_fixers = ['ktlint']
let b:ale_kotlin_ktlint_options = join([
  \ '--log-level=none',
  \ '--code-style=intellij_idea',
  \ ])

@voegelas
Copy link
Author

voegelas commented Sep 5, 2023

I've built a self-executable ktlint that defaults to "intellij_idea". I'm fine with this solution. No need to keep --code-style.

paul-dingemans added a commit that referenced this issue Sep 7, 2023
Pass parameter correctly to KtlintRuleEngine.

Also, deprecate parameters '--code-style', '--disabled-rules' and '--experimental' as those should be specified in the '.editorconfig' properties

Closes #2238
@paul-dingemans paul-dingemans unpinned this issue Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants