Fix test failure due to not displaying invisible characters

[krobelus]

test/main/emoji-test fails for me at emoji-commit-titles-col-300 because
this line is not rendered correctly:

2009-04-06 01:44 +0000 Committer o [master] 🌏💧✋🕋🗡🚀🏜☀️🌡🌶💯🚱⏳🌅🌑😡💉😱😈💀💥🌛🌙🐭💥🚶🏻〰🐛️⌛️👳🙏💥😴🛌😳💥🐛💥👊⚔👑

The line in emoji-test contains two 🐛emojis.
However, the first bug is followed by an invisible "Variation Selector".

Here are the two bugs with a \uFE0F in the middle:

🐛️🐛

It looks like Tig renders the first bug without \uFE0F, but the test
expects it.

The same goes for the next visible character after the first bug: ⌛ is
also followed by \uFE0F which is not rendered.

Fix the test failure by removing both invisible characters from the expected output.

This approach will probably break the test on other systems. I don't know
if the character should be rendered. I want to find out why it fails on my
system - maybe ncurses 6.2.1 doesn't render those control characters anymore?

[krobelus]

Travis fails (https://travis-ci.org/github/jonas/tig/jobs/752292336) so this seems wrong.
EDIT: this change is sufficient for the tests to pass in a fresh container running Ubuntu 20.04.

[koutcher]

With your PR, the test also fails on OS X 10.11... Did Ubuntu 20.04 fix something ? Or did it break something ? We need to find out before deciding what to do.

[krobelus]

Turns out this is because glibc's wcwidth in Ubuntu 16 assumes that 🐛 has a display width of 1, while later versions, like from Ubuntu 18 return 2:

#define _XOPEN_SOURCE
#include <wchar.h>
#include <stdio.h>
#include <locale.h>

int main() {
        if (setlocale(LC_CTYPE, "en_US.UTF-8"))
                printf("%d\n", wcwidth(0x1F41B));
}

For some reason, a single 0x1F41B ist still rendered as two cells on either system; I haven't figured out exactly why that's the case even if wcwidth is 1.

In our test, we want to render a string of two codepoints: {0x1F41B, 0xFE0F}
On old Ubuntu, ncurses would render two cells, with exactly those characters. Since the variation selector is nonprintable, the end result is correct.

On new Ubuntu, 0x1F41B is of width two, and therefore rendered in two cells with the same value. The variation selector is then attached to the second cell only. I'll test with a character where the variation selector actually makes a difference to see if "attaching to the last cell" can work.

So I think we can make the test cases a bit more interesting, but probably only if we know how wcwidth will behave. Maybe a check at configuration time is warranted.
The simplest fix would be to drop the variation selectors from the test input.

[koutcher]

Yes, I agree with you, I don't think it's worth having a complex test case just to make sure we don't break the display of a caterpillar in Tig...

[krobelus]

OK I've removed the variation selectors and updated the commit message. This seems to work on Ubuntu 16-20 and Mac EDIT: nvm, I didn't try on Mac.

[koutcher]

It runs fine on Mac as well.