@mwallnoefer @klag @kicito This looks good but I'm a bit in doubt about introducing a stateful configuration method (escapeControlChars). I just wanna point out that this is significant, but I don't see a good alternative, also because println/print can't get arguments.

We might wanna make this more explicit though, e.g., call the operation config and make escapeControlChars a parameter of config (for now the only one) or at least call the operation setEscapeControlChars. What do you think?

My proposal: Do we really need the "escape" flag on the print/println call on the Console service? In the sense, shouldn't special characters always be escaped there? Does there exist a valid reason to not have them escaped on a console output?

Of course this would be a breaking change against past Jolie releases and could also lead to incompatibilities. But I would need to know more about the context, @kicito. Please share it with us, otherwise it is very difficult to argue here.

There was a case where the API response included special characters that caused the terminal to misbehave when Jolie printed or dumped the response to the console. This PR introduces a workaround to handle such cases.

If we force escaping the special character, programs that rely on std out/in for communication might be affected by this change. It is rare nowadays (programs rely on special characters), but it is worth noting this potential side effect.

@fmontesi How about Jolie prints to stderr when encountering a special character, and it is the developer's task to handle the issue themselves (or with config operation as suggested)? IMO, we are dealing with an edge case, noting much Jolie should do about it.

What's the problem in adding an optional field in the request of println and print?

example:

type PrintRequest: string {
.escapeSpecialCharacters: bool // default true
}

mmmm this is a technical debt on the declaration of println and print. They should not be:

println( undefined )( void )

So, we could leave the undefined as a type, but adding a subfield escapeSpecialCharacter.
We can put the expected type as a comment and add a check on the print invocations, printing out a warning like:

WARNING: the undefined request type for println and print is deprecated. The expected type now is:
type PrintRequest: string {
.escapeSpecialCharacters: bool // default true
}
From version XX undefined will be replaced with the new one.

I agee with @klag: The Console Java service declares print() and println() with a String argument, so subfields have never been considered. If we introduce a escapeSpecialCharacters subfield we break the output of trees which (accidentally) contain a member with the exact same name. Is this so often the case?

        @RequestResponse
        public void print( String s ) {
...
        @RequestResponse
        public void println( String s ) {

That shouldn't be a big issue.

What's more of an issue is that I suspect there's quite some code invoking println by passing a value with fields, like println@console( x )() where x has a string root node and then subfields, because they got x by reading a file or invoking another service.

But this should be discouraged, indeed... and I guess we should just try and check if at least everything in the test directory works.

A good intermediate way would be to keep undefined as request type and just check if the parameter for escaping is present. What about that, @klag @mwallnoefer ?

New PR created here #635.