Seems to be terminal graphics/character anomalies when using XTerm, and just tested using rxvt-unicode terminal. I see quite a few ? or ???? question marks, as if some curses/ncurses characters could not be properly drawn.
Likely something to do with how curse/ncurses is used while working within Linux terminals. I now remember, hopefully correctly, kermit or minicom having a menu option for changing borders and other similar curses/ncurses graphics/characters (eg. borders), according to terminal types, such as Linux terminal, etc.
Although the readme does site unicode/UTF-8 drawing anomalies when not using unicode/UTF-8, it maybe I am using unicode within my terminals with or without knowing it. Usually prefixing, LANG="C.utf8" LC_ALL="C.utf8" program_name, within the terminal solves any anomalies if using ASCII. As things stand now, looks more likely wordgrinder-0.8.1 is either, not properly drawing/redrawing curses/ncurses characters or something other exquisite is occurring as I do not see these drawing anomalies at all within other curses/ncurses programs I quite commonly utilize here.
It maybe also, other more commonly utilized curses/ncurses programs avoids known exquisite problem cursus/ncurse characters/graphics, maybe the arrow graphic. For example, I've never seen, or rarely ever seen, the arrow graphic used elsewhere. All other commonly curses/ncurses seen/used characters/graphics seem to be drawing fine, or until switching display window and back again, for which a separate bug is opened.
Seems to be terminal graphics/character anomalies when using XTerm, and just tested using rxvt-unicode terminal. I see quite a few ? or ???? question marks, as if some curses/ncurses characters could not be properly drawn.
Likely something to do with how curse/ncurses is used while working within Linux terminals. I now remember, hopefully correctly, kermit or minicom having a menu option for changing borders and other similar curses/ncurses graphics/characters (eg. borders), according to terminal types, such as Linux terminal, etc.
Although the readme does site unicode/UTF-8 drawing anomalies when not using unicode/UTF-8, it maybe I am using unicode within my terminals with or without knowing it. Usually prefixing, LANG="C.utf8" LC_ALL="C.utf8" program_name, within the terminal solves any anomalies if using ASCII. As things stand now, looks more likely wordgrinder-0.8.1 is either, not properly drawing/redrawing curses/ncurses characters or something other exquisite is occurring as I do not see these drawing anomalies at all within other curses/ncurses programs I quite commonly utilize here.
It maybe also, other more commonly utilized curses/ncurses programs avoids known exquisite problem cursus/ncurse characters/graphics, maybe the arrow graphic. For example, I've never seen, or rarely ever seen, the arrow graphic used elsewhere. All other commonly curses/ncurses seen/used characters/graphics seem to be drawing fine, or until switching display window and back again, for which a separate bug is opened.