That doesn't even make sense - Cyrillic is Cyrillic, whatever the encoding is.
It's a property of the terminal whether or not Cyrillic characters are displayed single-width or double.
Xterm and gnome-terminal will display Cyrillic as single-width even if set to EUC-JP.
If I recall correctly, though, kterm would display Cyrillic in double-width (which was really ugly).
It might be worth looking into a cyrillic-is-double-width state variable, but I'm not sure how popular these terminals still are.
On the other hand, kanji as single width is still a common option in many terminals.
--
Alex
The function uc_width of GNU libunistring is a function determining
the terminal width of characters, much like what
unicode-terminal-width of SRFI 159 is supposed to do.
Contrary to unicode-terminal-width, uc_width takes a second argument,
namely the encoding used by the terminal (e.g. "UTF-8" or "EUC-JP").
And, indeed, after looking into the source code of uc_width, one sees
that the terminal character width may depend on the encoding:
/* In ancient CJK encodings, Cyrillic and most other characters are
double-width as well. */
if (uc >= 0x00A1 && uc < 0xFF61 && uc != 0x20A9
&& is_cjk_encoding (encoding))
return 2;
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/uniwidth/width.c#n462
To make unicode-terminal-width work with terminals using these legacy
encodings, it has to know the current encoding, which can be
associated with the port, for example. In any case, the current
encoding should be somehow part of the environment (i.e. the state
variables), in which the formatters are executed.
Unfortunately, unicode-terminal-width as currently specified is not a
monadic procedure and thus has no access to the state variables.
Marc