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 original wordwrap() command to a better "wordwrap function". I didn't change the createBlock() logic, in fact I fixed only the wordwrap() not the createBlock().

createBlock() is private and has an escape flag, i assume you either use e.g. comment() (no escape) and success() (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. Apparently createBlock() 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 that mb_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) and success() (escape) and only without escaping it breaks, isnt it?

1. There is a public block() function what I want to use to create custom blocks like comment() or success()
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 the strlen() and other string functions to their mb_* 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.php
String: őúáű
Simple: 8
MB: 4
# PHP 7.2
$ docker run --rm --volume $PWD:/app --workdir /app php:7.2-cli php test.php
String: őúáű
Simple: 8
MB: 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?

using formatAndWrap($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 from 4.2... I close it and I will make an other PR.

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

In: "This is a lorem ipsum test message."
Out (width=7):
This is
a lorem
ipsum t   <--????
est mes
sage.

Instead of:
This
is a lorem
ipsum
test
message
.

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 -).