--- Begin Message ---
|
Subject: |
Fwd: the font corruption problem - and the cause (for developers!) |
|
Date: |
Sun, 24 Apr 2005 00:40:38 +0200 (CEST) |
--------- Forwarded message ---------
From: Arpi <address@hidden>
To: address@hidden
Subject: the font corruption problem - and the cause (for developers!)
Hi,
[i'm not subscribed, to reply me please cc: me, thanks]
[also i'm not sure if this is the proper list for this,
if there is some developer list please forward, thanks]
So, there is a serious bug in 4.0.2 screen, reported
many times at many places, last time at:
http://lists.gnu.org/archive/html/screen-users/2005-03/msg00020.html
bad news:
- it is not related to centericq, i can easily reproduce with midnight
commander 4.6 (or cvs) too, and probably every app using the alternate
font set (^O and ^N codes to switch) for line drawing
- it's reproducible (at least for me) using TERM=xterm-color
(probably because only xterm-color supports alternate fonts this way?)
it also explains why people using framebuffer console couldnt reproduce.
- it's platform independent, i could reproduce on x86 linux with xterm,
and on mac osx using iterm or xterm.
- the bug is in screen. the app running in screen (mc in my case) sends
the ^O at the end of line drawing (tested), but screen eats it silently
(only the last one), so it stays in the alternate font mode.
if you now switch to other screen task, the font still isnt
changed, so the other screen is redrawn with the wrong font.
-> bug 1: why does screen eat the last ^O silently?
-> bug 2: why doesnt screen save/restore the font state for each task?
and yes, i have the correct terminfo and termcap entries for both
screen and xterm-color...
do the developers have any clue where is the bug, or should i
investigate more?
A'rpi / MPlayer, Astral & ESP-team
--
Girls are like internet domain names, the ones I like are already taken.
--- End Message ---
pgpPCrnoX0DtY.pgp