Skip to content
New issue

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

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

Already on GitHub? # to your account

Indentation-rule do code wrapping instead of just indentation #835

Closed
tprochazka opened this issue Aug 17, 2020 · 1 comment · Fixed by #1399
Closed

Indentation-rule do code wrapping instead of just indentation #835

tprochazka opened this issue Aug 17, 2020 · 1 comment · Fixed by #1399

Comments

@tprochazka
Copy link

I think that is quite problematic that Indentation-rule currently does more than indentation check, it actually checks line breaking and auto-formatting wrap code. I found that enable auto line breaking is too code-breaking for me and it is very hard to make it compatible with Android Studio, even when I apply code formatting setup by ktlint.

I generally don't like automatic line breaking and I prefer to do it manually. But I still want to check and fix the correct indentation. Would be please possible to split indentation and line-breaking to two different rules set, please?

@romtsn
Copy link
Collaborator

romtsn commented Aug 18, 2020

Yes, that's what we are planning to do (see #764) and the split you suggested would make a lot of sense imo

@paul-dingemans paul-dingemans added this to the 0.45.0 milestone Feb 16, 2022
paul-dingemans added a commit to paul-dingemans/ktlint that referenced this issue Mar 7, 2022
Wrapping logic belong in an own rule, so it can be disabled without
disabling the indentation logic.

The WrappingRule contains a simplified indentation logic. Whenever
a linebreak is inserted, it determines the indentation based on the
current indentation of the parent node regardless whether this node
is indented correctly. It is the responsibility of the
IndentationRule, which runs later than the WrappingRule to fix the
indentations.

Spec files used in the unit tests have been split. Some parts are
moved to new spec files specific for the WrappingRule. Other
parts are moved to real unit tests. And on some spec files,
both the wrapping and indentation rules are run together. Those
files need further refactoring.

The RuleExtension now also allows the diffFileLint and
diffFileFormat to run on a list of rules. Spec files which are
used for linting with multiple rules must specify the rule-id
in the expectations. The rule-id now optionally can also be
specified in those expectation when the file is checked by
only one rule. However, in case the detail property of the
LintError contains a ":" then the rule-id *must* be specified
as it is used as delimiter.

Closes pinterest#835
paul-dingemans added a commit that referenced this issue Mar 8, 2022
Wrapping logic belong in an own rule, so it can be disabled without
disabling the indentation logic.

The WrappingRule contains a simplified indentation logic. Whenever
a linebreak is inserted, it determines the indentation based on the
current indentation of the parent node regardless whether this node
is indented correctly. It is the responsibility of the
IndentationRule, which runs later than the WrappingRule to fix the
indentations.

Spec files used in the unit tests have been split. Some parts are
moved to new spec files specific for the WrappingRule. Other
parts are moved to real unit tests. And on some spec files,
both the wrapping and indentation rules are run together. Those
files need further refactoring.

The RuleExtension now also allows the diffFileLint and
diffFileFormat to run on a list of rules. Spec files which are
used for linting with multiple rules must specify the rule-id
in the expectations. The rule-id now optionally can also be
specified in those expectation when the file is checked by
only one rule. However, in case the detail property of the
LintError contains a ":" then the rule-id *must* be specified
as it is used as delimiter.

Closes #835
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants