Improve MINIMIZE_QUOTES
handling to avoid quoting for some use of #
and :
#201
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.
#181 and 2 more #180 related commits introduce some improved YAML scalars quoting more compliant to the YAML Spec, in the MINIMIZE_QUOTES mode; the updated behavior seems to be at least more strict (in quoting) than necessary, as it introduces quoting for any value containing chars as
#
and:
.If I am not mistaken YAML Spec states that such plain style limitation is applied for cases where the character combinations
#
(<space_or_tab>+<#>
) and:
(<:>+<space_or_tab>
) are present, not the single chars#
and:
.This PR updates behavior by considering the character combinations and not the single chars.
This has been triggered by an update of Jackson from 2.10.4 to 2.11.0 which caused YAML serialization test failures due to the difference in quoting, e.g. in case of scalar representing URIs, JSON references, date or datetime.
I understand that this is probably not a major issue, and e.g. code or tests can be adjusted in dependent projects and downstream, but I believe the affected scenarios are quite common and it would make sense to keep quotes at a minimum when
minimize
is on.Not sure if the target branch
2.11
is the correct one, was wondering if this could make it for 2.11.1 patch release in case.