@ro0NL Let's discuss! :) I fully refactored the code, I made a helper from it, and integrated intoTable andOutputFormetter. I changed a little bit your solution, and separated "wrapping" from "formatter" class because it would have been too complex in it.

I like this feature, but I'm concerned about the naming:

• I'd removePretty fromPrettyWordWrapperHelper because this feature is always called "Word Wrapping" ... so that should be enough. So,PrettyWordWrapperHelper ->WordWrapperHelper
• I'd removeLONG fromCUT_LONG_WORDS because words can be short and still be cut or not. So,CUT_LONG_WORDS ->CUT_WORDS
• I don't understand what these options do:CUT_FILL_UP_MISSING,CUT_ALL.

About CUT options/flags

@ro0NL and@javiereguiluz Before I reply for you one by one, I would like to clarify the importance of CUT options. I started this feature because of my existing other program, where I had to print some well formatted and colorized help/description texts, which were ugly with the existing output formatting solution. These are longer texts, with some URLs.
First I wrote a custom wrapper half year ago and I used it. My plan was that I will implement this function into Symfony when I have free time. While I was writing the code, I noticed that there are 2 big different situations because ofTable helper. As you can see here:https://github.com/symfony/symfony/pull/30519/files#diff-a3a53b968f8b0f15e54e6eeef311a73aR147 , first there was only one boolean "parameter" instead ofCUT options: $cutLongWords. Exactly it wasn't "my idea", I would have preferred if the implementedwordwrap() function had been similar to phpwordwrap() function:http://php.net/manual/en/function.wordwrap.php . So the$cutLongWords would have been same like the php$cut parameter in nativewordwrap().
But theTable console helper showed me, I didn't consider "very short" lines (<10-20 chars). The base solution isn't enough "responsive" :D I started thinking about other problems too, and because I would want to create a really flexible solution, first I added a second boolean parameter, and then a third, and that was the point when I thought, it would be too much:

publicfunctionwordwrap($string,$witdth,$cutLongWords =true,$cutURLs =false,$fillUpEnd =false, ...){// ...}

There are many other functions where there are lots of configuration options, e.g:

• json_encode() -http://php.net/manual/en/function.json-decode.php andhttp://php.net/manual/en/json.constants.php
• preg_match() -http://php.net/manual/en/function.preg-match.php
• file_put_contents() -http://php.net/manual/en/function.file-put-contents.php
• Yaml::dump()

If you have long rows (>50-60 chars) you may not need anyCUT options, but as you can see in the documentation at the CUT examples:https://github.com/symfony/symfony-docs/pull/11190/files#diff-8d05f5767d5a596b67434f76c113bb8dR80 , there are different "good" solutions, and I would like to leave the choice for the programmer, which one they want to use. Eg ($width = 4):

No cut:

Loremipsumdolorsitamet

Cut every words (sit andamet also):

Lorem ipsumdolor sit amet

Cut only the long words, that are longer than$width (sit andamet aren't cut)

Lorem ipsumdolorsitamet

Please look at the documentation too:https://github.com/symfony/symfony-docs/pull/11190/files , there are examples and after that maybe the conception will be clearer.

At this point, aren't we better of to rewrite the tag parsing as a whole? I.e. using a (real) lexer.

I was thinking about it also. I started to do a tokenizer/lexer, but I rejected it fast. The "grammar" is "too" simple. There are words and some simple tags. There aren't tag attributes, special characters, placeholders, etc. Yes, a lexer would be nicer, but we don't forget: this is the console block, for commands, what are used by programmers - in most cases -, and not "non-professional" users. We need a wrapper for "help/description/information" texts and for table cells. That's all.

Hello@javiereguiluz ,

thank you for your comment.

• I'd removePretty fromPrettyWordWrapperHelper because this feature is always called "Word Wrapping" ... so that should be enough. So,PrettyWordWrapperHelper ->WordWrapperHelper

OK, it was a good idea, I have changed it :)

• I'd removeLONG fromCUT_LONG_WORDS because words can be short and still be cut or not. So,CUT_LONG_WORDS ->CUT_WORDS

There exists aCUT_WORDS option, that means: cut every words (row length: 8 chars):

Lorem ipsum dolor sit amet

CUT_LONG_WORDS means: cut words that are longer, then a row, shorter words won't be cut (row length: 8 chars):

Loremipsumdolorsitametthisisaverylongword

• I don't understand what these options do:CUT_FILL_UP_MISSING,CUT_ALL.

CUT_FILL_UP_MISSING means: every row will be same length. It would be important when the line ha background color:

Default show:

▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧

WithCUT_FILL_UP_MISSING (every line is same length):

▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧▧

The missing characters are spaces, and the background color will "flow to line endings".

@ro0NL What if there was a<wrap> format style? I would keep theWordWrapperHelper, sometimes it could be useful, but people could use eg:

// It prints the text in a 8 char length, yellow background box$output->writeln('<wrap=8,fillup;bg=yellow>Lorem <info>ipsum</info> dolor sit amet.</>');

And I would refactor the text "pattern" with a lexer/tokenizer.

So, what I would do:

• SetWrappableOutputFormatterInterface to deprecated
• Remove my changes fromOutputFormatter, refactor it whit a lexer
• Add<wrap> "tag"
• Refactormax column width inTable (by adding<wrap> tag eg)