On Tue, Jan 06, 2026 at 07:10:35PM +0100, Jorgen Grahn wrote: > Package: xterm > Version: 398-1 > Severity: normal > Tags: l10n > > Dear Maintainer, > > I upgraded to Debian 13 the other day, and afterwards, switching > to/from UTF-8 text in xterm behaves differently. > > I made a test vector with both UTF-8 and iso8859-1 in it: > > % xxd xterm_test > 00000000: 7574 6638 3a20 2fc3 a52f c3a4 2fc3 b62f utf8: /../../../ > 00000010: e280 932f 0a6c 6174 696e 313a 202f e52f .../.latin1: /./ > 00000020: e42f f62f 2d2f 0a ././-/. > > Here are some steps which show the issue: > > 1. % LANG=C.utf8 LC_ALL=C.utf8 xterm > -> the xterm Ctrl-right button menu shows "UTF-8 Encoding" enabled > and greyed out (not possible to change) > -> the new shell has C.utf8 locale > -> 'cat xterm_test' renders the UTF-8 text properly > > 2. % LANG=sv_SE LC_ALL=sv_SE xterm > -> the xterm menu shows "UTF-8 Encoding" disabled > but possible to enable > -> the new shell has sv_SE locale > -> 'cat xterm_test' does not render the UTF-8 text properly; > renders the latin1 ok instead > > 3. Select "UTF-8 Encoding" in that menu. > -> 'cat xterm_test' still does not render the UTF-8 text properly; > renders the latin1 instead > > 4. Run 'reset' in the shell. > -> 'cat xterm_test' now renders the UTF-8 text properly. > > 5. Deselect "UTF-8 Encoding" again in the menu. > -> 'cat xterm_test' does not render the UTF-8 text properly. > > 6. Select "UTF-8 Encoding" again in the menu. > -> 'cat xterm_test' renders the UTF-8 text properly. > > So it seems that if you start out with a non-UTF-8 xterm but want to > switch to UTF-8, you need to both select "UTF-8 Encoding" in the menu > and run reset(1) in the terminal. After that, you can switch back and > forth using only the menu. > > I'm pretty sure this is a change compared to Debian 12 and earlier. > I.e. step 3 would have shown the UTF-8 text, with no need for step 4. > I will be able to confirm that, but not until Saturday when I have > access to a Debian 12 system. > > I should probably also disclose that I do my daily terminal work in > sv_SE, i.e. a non-utf8 locale. I have 35 years' worth of iso8859-1 > data which I don't fancy converting. I only switch to a UTF-8 locale > when I ssh to the host where I read my mail. I open a new xterm > dedicated to this, use the xterm menu to select "UTF-8 Encoding" and > "UTF-8 Fonts", and then: > > % LANG=sv_SE.UTF-8 LC_CTYPE=sv_SE.UTF-8 ssh -t aphanes mutt > > Aphanes runs OpenBSD, thus the odd locale names. Anyway this should > not be relevant to my problem -- unless you feel starting a non-UTF-8 > xterm is unsupported. In a quick check (since I have lots of versions compiled...) I see the change in #390 (almost two years ago). There's nothing specific to this feature in that change, but side-effects happen. Digging a little further I see that change in xterm-389h, which deals with UPSS. I see a few obscure possible (nothing definite), but with the clue from your report that a "reset" makes it workable, I can probably extend the chunk that does the switching to fill in whatever's needed. As a workaround, this works for me: tput rs2 and doesn't clear the screen. I adapted one of my test-scripts to do this along with the UTF-8 switching (see attached). -- Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net
#!/bin/sh # send character-string to enable UTF-8 mode if test ".$1" = ".off" ; then printf '\033%%@' else printf '\033%%G' fi tput rs2
Attachment:
signature.asc
Description: PGP signature