Unicode character support in screen tab names

[Explorer09]

I would like to share a feature that I have done as part of a code refactoring process.

These changes are still work in progress, but I think it's good to file it and gather early feedback.

This feature makes the screen tab names display with the correct terminal widths when they contain Unicode characters (in UTF-8 encoding). It replaces the naive strlen calculation with a new function that calculates the display terminal width of a name string.

The PR introduces the following functions:

• String_makePrintable, a sanitization function with an API similar toxStrndup. It reads the string, converts all unprintable characters to replacement code points (U+FFFD), and allocates and re-encodes the string.
• EncodePrintableString, an internal routine for String_makePrintable. This routine is designed with room to support RichString buffers
• String_mbswidth, a function that calculates the terminal width of a string, or calculate the byte length of a substring if it is clipped by a terminal width limit.

This PR is related to #1513.

[fasterit]

Fails CI:

XUtils.c:426:6: error: 'HAVE_STRNLEN' is not defined, evaluates to 0 [-Werror,-Wundef]
  426 | # if HAVE_STRNLEN
      |      ^
1 error generated.``

[Explorer09]

Fails CI:

XUtils.c:426:6: error: 'HAVE_STRNLEN' is not defined, evaluates to 0 [-Werror,-Wundef]
  426 | # if HAVE_STRNLEN
      |      ^
1 error generated.``

Noted. It should have been #ifdef.

[BenBE]

Fails CI:

XUtils.c:426:6: error: 'HAVE_STRNLEN' is not defined, evaluates to 0 [-Werror,-Wundef]
  426 | # if HAVE_STRNLEN
      |      ^
1 error generated.``

Noted. It should have been #ifdef.

IDK, but nowhere else do we check for strnlen, so why here all of a sudden?

[BenBE]

Any objections to pull in 4ccfc38335aaaaad3126844b7046e310a7cf6d59 to main now and do the Unicode support later? That commit is mostly cleanup and doesn't affect much of the later work in this PR.

[Explorer09]

Any objections to pull in 4ccfc38 to main now and do the Unicode support later? That commit is mostly cleanup and doesn't affect much of the later work in this PR.

I have just one question with the commit: Is it okay for the constants to be defined in CRT.h or is there a better header to put those two constant names?

BTW, I borrowed the "margin left" and "column gap" naming from CSS. 🙂

[BenBE]

Any objections to pull in 4ccfc38 to main now and do the Unicode support later? That commit is mostly cleanup and doesn't affect much of the later work in this PR.

I have just one question with the commit: Is it okay for the constants to be defined in CRT.h or is there a better header to put those two constant names?

CRT.h seems to be fine. ScreenManager.h may be another place to put them, but actually I'm not too sure, where's best …

BTW, I borrowed the "margin left" and "column gap" naming from CSS. 🙂

Fine.

[Explorer09]

I have just one question with the commit: Is it okay for the constants to be defined in CRT.h or is there a better header to put those two constant names?

CRT.h seems to be fine. ScreenManager.h may be another place to put them, but actually I'm not too sure, where's best …

Action.c does not include ScreenManager.h. If I define the constants in ScreenManager.h, then Action.c would need another include line. Hence I avoided that in the first place.