Tools: Optical issue with NXF ansi

[apeltzer]

Hi everyone,

just found out that the new and now default ansi Nextflow log seems to malform our colored output on the console a bit:

Running the same nextflow version with -ansi-log false gives this:

(as we wanted it).

I just wanted to make that behavior documented here, to give @pditommaso some feedback 👍

(similar behavior when working with the rnaseq, eager etc pipelines - seems to be something introduced with Nextflow 19.04.X)

[apeltzer]

I'm talking about the 2m[ created by parts of this template snippet here:

https://github.com/nf-core/tools/blob/4ab80b83cd8b6562a88bb38b6aa0a3d082fd4de6/nf_core/pipeline-template/%7B%7Bcookiecutter.name_noslash%7D%7D/main.nf#L154

[drpatelh]

https://github.com/nextflow-io/nextflow/issues/1129

Hopefully, it's just a case of updating the template with another ANSI code.

[apeltzer]

I guess its just that yes 👍

[apeltzer]

Although the stated ones are actually correct:
https://devhints.io/ansi

[phue]

It seems that the the first character in the multi line String is the ${c_dim} variable, that is not properly escaped for some reason.

The simplest 'fix' probably is to either remove c_dim from the first line or insert a newline before.

[pditommaso]

I think it gets messed up with the library used by NF to render the ansi code.

https://github.com/nextflow-io/nextflow/blob/95f4dd7bddd30087b7d17571364c881d2e1e161a/modules/nextflow/src/main/groovy/nextflow/trace/AnsiLogObserver.groovy#L258-L266

Likely it escapes the ANSI code because it's not expecting it ..

[ewels]

Can / should we use the same library instead of hardcoding the colour codes?

[apeltzer]

That would be ideal if this is possible :+1: