can you provide some code / console output that lead to this fix? I tend to believe it's a new feature instead, where we would preserve raw formatting.

Not sure createBlock() should try that, as it's not really supported to use nested markup here (given the block itself uses markup); or at least is interpreted as raw text.

cc@chalasr

Hello@ro0NL ,

can you provide some code / console output that lead to this fix? I tend to believe it's a new feature instead, where we would preserve raw formatting.

I have a command with longer and detailed help texts with many colored words or signs to be readable, eg:<fg=yellow;options=bold>[!]</>,You can see information about all available wizards with <info>h</info>. If the name is <comment>yellow</comment> the program is unavailable here. The reason would be there are missing requires OR it has already built/run. Use the <comment>--force</comment> option to disable this check. You can read more information with <comment>wizard --help</comment> command.
And if I remember well - I made this fix 4 months ago -, sometimes there is a help link that were broken in the oroginal solution, and they weren't clickable in the terminal.

The output was really ugly sometimes because of many "hidden" formatter tags, the length of lines were very changing.

Not sure createBlock() should try that, as it's not really supported to use nested markup here (given the block itself uses markup); or at least is interpreted as raw text.

I changed only the originalwordwrap() command to a better "wordwrap function". I didn't change thecreateBlock() logic, in fact I fixed only thewordwrap() not thecreateBlock().

createBlock() is private and has an escape flag, i assume you either use e.g.comment() (no escape) andsuccess() (escape) and only without escaping it breaks, isnt it?

ive added formatted text wrapping in#22225, perhaps we can use it here? and render the result as-is (OUTPUT_RAW), sounds more simple :D

for the case with escaping, e.g.<tag\nbreaks> im not sure we care. ApparentlycreateBlock() can do both :) didnt recall that.

Is there anybody who knows what the problem could be here?https://travis-ci.org/symfony/symfony/jobs/504759370 I can see that one test is failed, but it should be good, it works fine at me and on 7.2 also. It looks like thatmb_strlen() works wrong on PHP5.5. Is it possible?

@ro0NL

createBlock() is private and has an escape flag, i assume you either use e.g.comment() (no escape) andsuccess() (escape) and only without escaping it breaks, isnt it?

1. There is a publicblock() function what I want to use to create custom blocks likecomment() orsuccess()
2. It breaks the URLs as well. It could be annoying.
3. It could handle UTF-8 characters wrong also. See below.

ive added formatted text wrapping in#22225, perhaps we can use it here? and render the result as-is (OUTPUT_RAW), sounds more simple :D

I looked at this, and yes, it could be good. As I can see I should refactor everywhere thestrlen() and other string functions to theirmb_* version.

<?php// test.php$string ='őúáű';$simple =strlen($string);$mb =mb_strlen($string);printf("String: %s\nSimple: %d\nMB: %d",$string,$simple,$mb);

# PHP 5.6$ docker run --rm --volume$PWD:/app --workdir /app php:5.6-cli php test.phpString: őúáűSimple: 8MB: 4# PHP 7.2$ docker run --rm --volume$PWD:/app --workdir /app php:7.2-cli php test.phpString: őúáűSimple: 8MB: 4

for the UTF related issue, would it be better to create a separate PR?

ive added formatted text wrapping in#22225, perhaps we can use it here? and render the result as-is (OUTPUT_RAW), sounds more simple :D

I looked at this, and yes, it could be good.

based on the amount of code here (and a new feature (breaking tags) of which im not sure we need it) i would prefer that route.

@ro0NL

for the UTF related issue, would it be better to create a separate PR?

Yes, I agree with this.

based on the amount of code here (and a new feature (breaking tags) of which im not sure we need it) i would prefer that route.

It isn't clear exactly for me. Which route do you prefer?

Which route do you prefer?

usingformatAndWrap($txtWithTags, $maxWidth). The formatted result is wrapped in the "unformatted block content", this combination is then rendered by writeln()

I think even we dont need to change the OUTPUT_ type, using OUTPUT_NORMAL will preserve existing formatted text i expect.

@ro0NL

OK, but it is only available from4.2... I close it and I will make an other PR.

@ro0NL Oh, I have just seen that theformatAndWrap() solution is "too simple":

In: "This is a lorem ipsum test message."Out (width=7):This isa loremipsum t   <--????est message.Instead of:Thisis a loremipsumtestmessage.

It could be OK in shorter place (<30 chars, eg: table cell), but it isn't same what I made.

is a lorem is 10 chars :D

i think we should first focus on correct rendering (not breaking visual output). Then later on we can try to patch formatAndWrap to be more clever concerning 'word breaks' (but never exceed the max width; so worst case we would still chop up words, or more clever with a dash-).