The ps command should automatically insert newlines to avoid line breaks in the middle of words.

[PaulJuliusMartinez]

The ps command will unescape a JSON string (except for control characters) and then print it to the terminal. Currently, it will just write the string to the terminal directly, so if the string is longer than the width of the terminal (likely, if someone is using this command), the text will automatically wrap when it reaches the edge of the terminal, even if in the middle of the word. This is undesirable. We should automatically detect word boundaries and automatically insert new lines.

Bad:                         |
The quick brown fox jumped ov|
er the lazy dog.             |
                             |
Good:                        |
The quick brown fox jumped   |
over the lazy dog.           |

Initially I thought this was a bad idea, because if you then highlighted the text to copy it, you would copy the line breaks that weren't there originally. If your terminal supports terminal reflow (as do both macOS's default terminal and iTerm 2), then highlighting and copying the first version won't copy any line breaks.

But this is a bad argument, because there's already a separate command, ys, for yanking a string to your clipboard. You should use that if you want to copy! But I suppose that you may only want to copy a small section, and I also implemented ps explicitly as a fallback if the built-in clipboard functionality was not working.

An argument against inserting hard line breaks is that you no longer get to take advantage of Terminal reflow. If I printed out text that was too long, I think zooming out or making my window full screen would be my first reaction, and neither would help here, because the text wouldn't reflow. But also I think maybe I'd only do that if the output suggested that the text was already wrapped to a certain width, like this:

// Naturally, there may be cases where an enti
re line does not fit
// on the screen without wrapping. Rather than
 implement line
// wrapping (which seems difficult), we trunca
te values and show
// ellipses to indicate truncated content. Whe
n printing out multiple

And probably unformatted text is more common than pre-wrapped text (or stack traces, or log lines)...

I don't want to have two separate commands, because it's such a subtle distinction for a small feature that no one will ever remember the two. I think I vote for inserting newlines to avoid line breaks in the middle of words.