Horizontal line in "Objects have changed outside of terraform" output looks like a tmux pane split

[geekofalltrades]

Terraform Version

$ terraform version
Terraform v0.15.4
on linux_amd64

Terraform Configuration Files

...

Debug Output

Crash Output

Expected Behavior

Actual Behavior

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

...

Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

...

To users of tmux, the horizontal line spanning the terminal width in this output looks like a horizontal pane split, which is confusing.

In this image, the vertical line on the left is a pane split. The horizontal line in the middle is not, it's part of the Terraform output.

Steps to Reproduce

Additional Context

References

[apparentlymart]

Hi @geekofalltrades! Thanks for reporting this.

I think it's fair to say that this collision of styles is unfortunate, but it's not really a bug because it's by design and is a reasonable use of the limited set of box drawing characters available in the context of a terminal. For that reason, I'm going to relabel this as an enhancement and then we can use this issue to evaluate how significant an issue this is and what we might do about it.

Obviously tmux doesn't have a monopoly on drawing boxes using the Unicode box drawing characters, but I do agree that for someone using tmux this creates some ambiguity. What we might do about that is debatable: there are other available box drawing characters in Unicode, but this thin single line is one that has good coverage in a variety of monospace fonts and so selecting another one, as well as being subjectively different, also risks creating problems for folks using a terminal font with more limited character repertoire.

I have a feeling that this one is going to end up being a situation where we acknowledge that it's unfortunate but accept it anyway, but if you know of other applications that have taken steps to avoid being ambiguous with the characters tmux selected then we'd love to hear about them and consider taking a similar approach as they did.