(Edited to clarify the role of Emacs in the problem with the display.)
gnu-screen session has gotten corrupted somehow, and Emacs fails to display UTF-8 characters properly.
I've confirmed that in freshly-started
gnu-screen processes, Emacs displays UTF-8 characters properly, but at the moment it would be very disruptive to replace the corrupted
gnu-screen session with a new one, and instead
I'm looking for ways to further troubleshoot the problem with this corrupted
gnu-screensession, and hopefully fix it.
FWIW, I give more background below, including a description of what I've done so far to diagnose the problem.
I started this
gnu-screen session several days ago at my OS X workstation at work with
% screen -U
...(as I always do). Since then I have re-attached this session from several machines (possibly after first
ssh-ing to my workstation at work) using
% screen -U -dR
(again, this is what I always do). I did precisely this this morning at my workstation at work (the machine where the
gnu-screen process is actually running).
Today, for the first time since I created this
gnu-screen session, I needed to work with files that contain a lot of non-ascii UTF-8 characters. It was then that I discovered that this
gnu-screen session must have gotten corrupted somehow, because it displays all these characters as
?, resulting in an unusable display.
(As I already alluded to, these UTF-8-rich files are displayed correctly by freshly-started
gnu-screen sessions, so I'm pretty sure that the display problem is with the particular
gnu-screen session that here I'm calling "corrupted". Also, I confirmed that the "
??? display" shows up in every terminal that I have attached the
gnu-screen session from, so the problem is not with the terminal program hosting the
gnu-screen session. Lastly, I also confirmed that the problem is not with one particular Emacs session: in the corrupted
gnu-screen session, every new Emacs sessions displays the UTF-8 characters as
?, which argues against the problem being with a particular Emacs session.)
I've confirmed that
on by running
:utf8 on on
The output of
(1,5)/(210,52)+10000 +(-)flow app log UTF-8 0(zsh)
% /usr/local/bin/screen --version Screen version 4.00.03 (FAU) 23-Oct-06
Also, I should point out that new
What else can I do to troubleshoot this problem?
UPDATE: Drav Sloan and Stephane Chazelas both asked about my locale settings:
% locale LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL=
Currently, for OS X I don't set any locale-related variables.
On Linux systems, my
.zshenv does set
export LANG=en_US.utf8 export LC_ALL=en_US.utf8
...but if I put the same lines in my .zshenv on Darwin, I get error messages to the effect that "setting locale failed." I vaguely remember bashing my skull for several hours over the problem of finding the right locale settings for Darwin/Lion. It may have been that "setting nothing" emerged as the "least awful" solution to the problem and, after all, at least fresh
gnu-screen sessions do display UTF-8 characters correctly, even in the absence of an explicit locale setting. But clearly I need to figure out how to properly set locale in Darwin/Lion...
UPDATE2: OK, I think I figured out the reason for the errors I mentioned above: in Darwin/Lion, the string
en_US.utf8 is invalid; instead it should be