Long descriptions break output

[davidtheclark]

With this test ...

var test = require('tape');

test('long description', function(t) {
  t.equal(0, 0, "this is a very long description this is a very long description this is a very long description")
  t.end()
});

... my output looks like this:

# long description
✓ long descriptionery long description this is a very long description this is a very long descripti# tests 1
# pass  1
✓ ok

I notice that if I delete the last two characters, making it a 93 character long description, the weird printing doesn't happen. Same goes for a description that is just a lot of a: up to 93 works; over 93 causes this weirdness.

[davidmason]

I am seeing a similar thing. It looks like the total line length of the output is the problem, so I have some lines of 103 characters later in my test suite that cause no problems, but when I add a test before it and the test number is a digit longer, it chokes on the 104 character line.

Totally fine:

ok 944 should have only expected classNames at path (root)<ul>[3]<li>[0]<div>[2]<label>[0]<div>[0]<svg>

Broken

ok 1023 should have only expected classNames at path (root)<ul>[3]<li>[0]<div>[2]<label>[0]<div>[0]<svg>

Where the output would like:

✓ TransUnitFilter markup

a single long line makes it:

# TransUnitFilter markup
  ok 1023 should have only expected classNames at path (root)<ul>[3]<li>[0]<div>[2]<label>[0]<div>[0]<svg✓ TransUnitFilter markuply expected classNames at path (root)<ul>[4]<li>[0]<div>[2]<label>[0]<div>[0]<svg

[davidmason]

Looks like the line length that triggers this depends how wide my terminal is. If I zoom my terminal out or stretch it across the whole screen, I get none of the display issues. If I reduce it to a very narrow width then re-run my tests, most of the "ok ..." lines appear.

@davidtheclark can you try your case with terminals that have a different number of columns and see if the description length changes?

@substack I don't know where I would start trying to fix this. Any idea what would make this happen?

[davidtheclark]

@davidmason I can confirm that it is connected to the width of the terminal. If my terminal is wide enough that no lines overflow, I do not see the problem.

[mpj]

@davidmason @davidtheclark Confirming here too.

[awlayton]

The problem seems to come from this line producing a string that ignores the value of opts.width.

I tried putting trim( ) around it, but then the strings were cut much shorter than the width of my terminal...

[davidmason]

Sounds like it just needs something like wrap(...) that will wrap each line to no more than a given number of chars. Should be straightforward to implement if something like it doesn't already exist (I would be surprised if it doesn't though).

[awlayton]

@davidmason yeah that's the sort of thing the trim function in there does, but I apparently used it wrong. I don't quite follow the code, so I gave up on fixing it myself.

[abalmos]

+1

[ratiotile]

I am having the same problem, but with only 65 character long descriptions. However, the limit seems to get larger if I run the test manually, and shorter if the test is run using nodemon. In other words, the same test code run directly will output fine, but be corrupted when run with nodemon.

Also, corruption that appears on one line will 'infect' other lines that used to print ok, and this induced corruption on other lines will go away as soon as the one line is shortened.

[ljharb]

I think is also #30; fixed in #29.