This initial analysis is not entirely accurate. For the correct analysis, follow the discussion in this pull request.
I've looked into this a bit more, and this mojibake is caused by passing UTF-8 line-drawing chars. to ncurses functions which take old-fashioned ASCII text.
For example, take the print_hline
and print_vline
functions in cursive
, which are used to draw horiz. and vert. lines for boxes. These functions pass a UTF-8 char for the bar char. The print_hline
and print_vline
functions call print_at
or print_at_rep
which in turn call the backend's mvaddstr()
. Which, is wrong.
The curses mvaddstr()
or addstr()
only accepts ASCII or VT100 line-drawing chars. For writing UTF-8, curses
provides different functions: add_wchstr()
and mvadd_wchstr()
. But, here's the rub: the backends don't implement these functions.
What's to be done, then?
1. The correct solution is to fix both the backend (ncurses, pancurses, ...) and cursive to call the UTF-8 aware functions.
2. As a hack, patch cursive
to send ASCII chars. for the glyphs down to the backends instead of UTF-8 ones. This should be trivial to do. I'll do it--if nobody else does it.