Support wide-character ncurses output

[vrza]

Wide characters (UTF-8) in strings like location names don't render properly in curses UI when linked with -lncurses.

On my Linux system, simply linking against -lncursesw instead of -lncurses does the trick.

I'd propose a patch but after some tinkering I am not sure how to go about patching project's current configure.ac to automatically detect ncursesw -- perhaps m4 macros that come with newer autotools can solve this.

[benmwebb]

Odd, I found that plain ncurses displayed most of the accented characters used in the various translations without issues, last time I looked on Mac and Linux. But it would be easy enough to modify configure.ac to check for ncursesw. Just add another AC_CHECK_LIB to the nested if statements around https://github.com/benmwebb/dopewars/blob/v1.6.2/configure.ac#L160-L176.

[vrza]

You sure you tried it with wide-character (notably, UTF-8) locales, and not e.g. ISO-8859-1 locales?

As an example, here's how the output looks with LANG="de_DE.UTF-8":

On Fedora Linux, -lncursesw is sufficient to make wide character locales work.

On Gentoo Linux, I needed to link with -lncursesw -ltinfow.

I did originally try using that AC_CHECK_LIB macro to detect ncursesw, for example:

   if test "$CURSES_CLIENT" != "no" ; then
      AC_CHECK_LIB(ncursesw,newterm)
      if test "$ac_cv_lib_ncursesw_newterm" = "no" ; then
        AC_CHECK_LIB(ncurses,newterm)
        if test "$ac_cv_lib_ncurses_newterm" = "no" ; then

but that would break the includes:

checking for newterm in -lncursesw... yes
...
curses_client.c:49:8: error: unknown type name ‘SCREEN’
   49 | static SCREEN *cur_screen;
      |        ^~~~~~

I'm not sure how to control include and linker flags more precisely using AC_CHECK_LIB.

I'm also unsure when we need to link against tinfo and when we don't need to, but always looking for it doesn't seem to hurt and that can be done with AC_CHECK_LIB(tinfo,cbreak).

I found a specific macro AX_WITH_CURSES, and that seems to promise proper curses detection on a variety of platforms, but replacing AC_CHECK_LIB with it was not straightforward either (works on Gentoo, breaks autogen.sh on Fedora).

[vrza]

Okay, I've been able to solve for both ncursesw and tinfo with AC_CHECK_LIB, tested on Fedora and Gentoo, here's a PR #72

[vrza]

Feature branch for solution using AX_WITH_CURSES macro is here:

https://github.com/vrza/dopewars/tree/ax_with_curses

[vrza]

Fixed AX_WITH_CURSES branch on Fedora, by satisfying a dependency for the macro.

Here's another PR #73. This approach is likely more robust and more portable.

[vrza]

Following up to make sure cur_colr lib detection is not inadvertently broken.

After #74 is merged it should at least work the same as before, although I have no way of testing with this particular Curses variant.

[benmwebb]

Following up to make sure cur_colr lib detection is not inadvertently broken.

#74 looks good to me. I also cannot test this. cur_colr was needed, IIRC, to get the code to build on a Tru64 system 20 years ago... but Tru64 has long since been retired. We may as well keep the existing code though.

[vrza]

Thanks for sharing that bit of info.

I did a casual google search and found cur_colr referenced in IBM Informix knowledge base, where users of Informix Tools 7.50 on HP-UX were instructed to create symlinks from curses/xcurses to cur_colr. Informix 7.50 was released in 2008.

From this article it seems that HP-UX in 2008 did not have cur_colr, probably never had it, so HP-UX should, at least in theory, be covered by the AX_WITH_CURSES macro.

Last version of Tru64 was released in 2010.

Nevertheless, we agree that it does not hurt to keep cur_colr detection code in.