Ignore tokens between backticks in rule max line length (#1007) #1008
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
December 12, 2020 21:06
Tokens starting and ending with a backtick should be ignored entirely when validating whether a line exceeds the maximum length of a line. Such tokens can not be spit into multiple lines. For example when writing JUnit test it is a common pattern to write the function names between back ticks instead of using the DisplayName annotation.
|
The identifiers between back ticks can now optionally be ignored. By default this option is disabled so the behaviour is not changed for existing users. |
|
@Tapchicoma Sorry that I reach out to you in this way but I have found no other way to do so. I am wondering what else I can do to get my PR's merged. I am aware that you are volunteer on this project. I am willingly to give a long term commitment on the project if you would appreciate that. But for that I need to know how my contributions will be merged more smoothly. |
|
@paul-dingemans sorry for missing your last comment in this PR. As far as I know @romtsn want to review your PRs. Regarding #1038 PR, that I've started to review, could you split it into two:
|
Previously, when ktlint failed to find '.editorconfig', file path was not passed to the rules. This lead for wrong "filename" rule behaviour.
To clarify how the IntelliJ IDEA code style setting configuration process works, add an brief explanation about what each command does and clarify that the code samples are command line calls, not config file entries
…EditorConfig is set (pinterest#1010)
* Deprecate shorcuts for import-ordering * Update CHANGELOG.md
pinterest#1027) Solves pinterest#1013 Co-authored-by: Paul Dingemans <pdingemans@bol.com>
…emoved (pinterest#1026) * Fix string-template for dot-expression of which the redundant toString is removed (pinterest#996) The no-unused-imports rule fails on the existence of the dot-expression node but for which the actual call to the toString method was removed. * Update changelog * Fix code style violation Co-authored-by: Paul Dingemans <pdingemans@bol.com> Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
…g indentation style (pinterest#425) (pinterest#1031) Co-authored-by: Paul Dingemans <pdingemans@bol.com>
* Add CI & Mega-Linter link in README * Add CI link to head menu
…efore-assignment`) (pinterest#1041) * Don't remove the equals sign for a default argument (`no-line-break-before-assignment`) * Remove unnecessary test * Remove unused import Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
Changelog: https://docs.gradle.org/6.8.1/release-notes.html Has to slightly increase Gradle maximum allowed memory usage to prevent heap out of space sporadic errors.
MacPorts also works on Linux
…ting file with many corrections (pinterest#1083)
Initialization error happens only when using from KtLint CLI with Kotlin versions 1.4.20+. Via `java jar ktlint-cli.jar` approach Kotlin compiler initializes without failures. For now added workaround, but, in the future, CLI approach should revisited.
Enable new JVM IR backend.
* Fixing bug with experiment:annotation-spacing-rule with comments * updating changelog * deleting unused function * fix imports * fix build
Migrate method to get all mathing globs files to use internally 'PathMatcher' and 'FileVisitor' instead of using klob dependency. Fix negated globs passed to CLI are no longer worked.
Kotlin dev is set to 1.5.0-M1. Kotlin pre-releases are now available on Maven Central.
|
hi @paul-dingemans, sorry for the long-awaited review, I've just changed 3 things:
I will take your frustration on me, as I planned to do the aforementioned changes way earlier, but then life happened. Your PRs are of course appreciated, just one wish would be to make your PRs smaller and target one specific issue/thing (I'm referring to your other PRs, this one looks good). thanks for the contribution! |
This was referenced Mar 8, 2021
romtsn
pushed a commit
to paul-dingemans/ktlint
that referenced
this pull request
Aug 8, 2021
…) (pinterest#1008) * Ignore tokens between backticks in rule max line length (pinterest#1007) Tokens starting and ending with a backtick should be ignored entirely when validating whether a line exceeds the maximum length of a line. Such tokens can not be spit into multiple lines. For example when writing JUnit test it is a common pattern to write the function names between back ticks instead of using the DisplayName annotation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tokens starting and ending with a backtick should be ignored entirely when validating whether a line exceeds the maximum length of a line. Such tokens can not be spit into multiple lines. For example when writing JUnit test it is a common pattern to write the function names between back ticks instead of using the DisplayName annotation.
Currently I just ignore all ASTNodes starting and ending with a back tick. Such a node no longer counts in the calculation of the length of the line. This is not explicitly limited to method names neither to unit test only. However I do think this approach is valid. Tokens can only contain back ticked values whenever this is allowed by Kotlin. Such tokens can never be split in multiple lines.