Earlier this week I ran into a pesky issue when using slrn on a remote machine, inside Screen, over an SSH session, via rxvt, running under Cygwin on a WinXP box. The problem looked like this, and seems to be some sort of either character-encoding or display problem with non-ASCII characters used in slrn’s text-mode interface.

It’s an obnoxious problem because it rather seriously interferes with slrn’s thread-tree display, and because there are so many different layers involved, any of which could be to blame. Starting from the user and working backwards towards the source, there’s rxvt, SSH, Cygwin, Windows, Screen, slrn, and Linux, any of which could be causing it. (Although some are a lot more likely than others.)

The simplest and least elegant way to solve the problem is just to force slrn into pure-ASCII mode, by putting

set simulate_graphic_chars 1

into .slrnrc. However, that just seems wrong. VT100 box-drawing characters, which is all slrn seems to be using, aren’t exactly high-tech stuff — we’re talking about the very best of 1978, here. This isn’t Unicode or anything sexy; it’s just an alternate 7-bit character set triggered by “shifting in” and “shifting out” using escape sequences.

I think the problem is probably a termcap/terminfo issue, but I haven’t been able to get any results via any combination of terminfo settings that I’ve tried.