The expression editor uses 8-bit characters and 8-bit ncurses functions. It might not be too challenging to modify it to use wide characters and the wide ncursesw functions, though it might take more than cosmetic changes. If you disable the expression editor (`scheme --eedisable``) Unicode should already work in a terminal emulator that supports it.

I've spent a bunch of time today reading code, and I think I have a straightforward way of doing this, but I wanted to check here first. There are three parts to it.

1. Write characters to the console using wctombs, which will respect the current locale (and should output utf8 in anything modern).
2. Read characters from the console, covering with mbrtowc() tracking an mbstate_t in static variables in s_ee_read_char() (the windows code does something similar), with care to respect the blocking flag. This will require handling a few different cases (like EWOULDBLOCK in the middle of a Unicode sequence).
3. Make the key mapping in expeditor.ss allow characters over 255. (We could survive without this, but seems like a good idea.) ???

None of this handles Unicode character composition, but it would allow all precomposed characters, emoji, and what not. AFAICT, character composition would require retrofitting a significant about of math in expeditor.ss.

So, before I embark, is this a decent approach? Can you think of anything specific I'll need to address to get this code accepted?

Have you looked into using the "wide" version of ncurses (ncursesw)? If it works, it should simplify the input side; plus I'm not sure the non-wide ncurses will even deliver multibyte input characters.

@dybvig I did, but I found this which suggested a different approach.

It looks like I have a bug to work out, but I'll push what I have, which is mostly working for review.

Thanks for the pointer to the comment. I had forgotten curses getch.required that we go full screen.

I believe this has since been fixed.