From: Christian Weisgerber Subject: Re: tog test harness To: gameoftrees@openbsd.org Date: Sat, 15 Apr 2023 20:12:28 +0200 Mark Jamsek: > The below diff implements the framework for tog automated tests. I have some comments on the tog.c changes: > +#define TOG_SCREEN_DUMP "SCREENDUMP" > +#define TOG_SCREEN_DUMP_LEN (sizeof(TOG_SCREEN_DUMP) - 1) Why is this worth separate defines, when you use "KEY_ENTER" etc verbatim in tog_read_script_key()? > +/* > + * Extract visible substring of line y from the curses screen > + * and strip trailing whitespace. If vline is set and locale is > + * UTF-8, overwrite line[vline] with '|' because the ACS_VLINE > + * character is written out as 'x'. Write the line to file f. > + */ What does the locale have to do with it? If anything, it would suggest the use of UTF-8 line-drawing characters. The line drawing characters chosen by ncurses primarily depend on $TERM and the termcap/terinfo entry. For VT100-compatible terminals, you'd expect a switch to the Alternate Character Set, and 'x' which is then rendered as a vertical line. I don't think we want to try to predict the entire interaction between termcap/terminfo, ncurses, the terminal, and for all I know, yes, even the locale. Maybe overwrite the character unconditionally? > /* > + * XXX Perhaps we should define "xterm" as the terminal > + * type for standardised testing instead of using $TERM? > + */ Yes, you should use a standardized $TERM. I mean what happens for TERM=dumb? I'm not sure what a good choice is. "xterm" feels like a moving target. -- Christian "naddy" Weisgerber naddy@mips.inka.de