command/format: multi-line rendering for unchanged strings #23305
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.
We have a special treatment for multi-line strings that are being updated in-place where we show them across multiple lines in the plan output, but we didn't use that same treatment for rendering multi-line strings in isolation such as when they are being added for the first time.
Here we detect when we're rendering a multi-line string in a no-change situation and render it using the diff renderer instead, using the same value for old and new and thus producing a multi-line result without any diff markers at all.
This improves consistency between the change and no-change cases, and makes multi-line strings (such as YAML in block mode) readable in all cases.
Before:
After:
This fixes #21817 as closely as we can within our existing diff heuristics. Specifically, the new treatment of the list-of-multiline-strings case is improved but still not ideal because the list diffing algorithm only ever produces additions and removals and never in-place updates, so a list like the
values
in that issue's example would use the above multi-line rendering for both the old and new values but would not interleave them into a single line-oriented diff because it doesn't understand that the new element zero is intended as an in-place edit to the old element zero, rather than a replacement. Maybe we'll improve on that further someday, but for now just showing the lines of the string in full should hopefully be a reasonable compromise.