Bug 128341

Summary: redrawwing problem in xterm
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: xtermAssignee: Mike A. Harris <mharris>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dickey
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-08 00:39:50 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
specfile upped to version 194 and patch for bug 128138 added
none
patch fixing bug 128138 none

Description Hans de Goede 2004-07-21 18:14:35 EDT
-run mc from a real xterm on fedora core 3 test1 (english, UTF8 char
encoding)
-left pane active
-place some window partially over the xterm
-raise xterm, this causes mc to redraw
-the line after the "cursor/selection" on the right pane
 goes black.
-pressing ctrl-l fixes things up.
Comment 1 Hans de Goede 2004-07-21 18:15:09 EDT
I've also reported this upstream:
https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=9723
Comment 2 Thomas E. Dickey 2004-07-21 19:40:40 EDT
I've seen this and it's been reported to me (a few months ago).
(It was on a list of things I checked on this weekend, but was
not cooperative enough to be reproducible).
Comment 3 Hans de Goede 2004-07-22 01:56:46 EDT
Well its 100% reproducable over here,
xterm, LANG=en_US.UTF-8, TERM=xterm-new, ncurses-5.4 (without any
patches to the xterm-new entry), mc-4.6.0

Just follow the steps described above.
Comment 4 Thomas E. Dickey 2004-07-24 10:24:03 EDT
I did that (several times last weekend, but perhaps it was
obscured by a fix I made for handling NotifyGrab events).
When I revisit xterm tomorrow, I'll continue looking for this.
Comment 5 Thomas E. Dickey 2004-07-26 16:03:00 EDT
I have a fix for this, will make a patch today or tomorrow.
Comment 6 Thomas E. Dickey 2004-07-27 20:52:20 EDT
fix is committed in xterm patch #194.
Comment 7 Hans de Goede 2004-07-28 02:32:14 EDT
I can confirm xterm-194 fixes this!

I'll attach a specfile for 194 (shocking change) and the patch for bug
128138. Note this exactly the same patch as in bug 128138, but now
I've made it against the xterm srcs instead of the installed
appdefault file, so that it can be used during the rpm build.
Comment 8 Hans de Goede 2004-07-28 02:33:52 EDT
Created attachment 102242 [details]
specfile upped to version 194 and patch for bug 128138 added
Comment 9 Hans de Goede 2004-07-28 02:35:21 EDT
Created attachment 102243 [details]
patch fixing bug 128138

p.s.

I had reported this upstream as an mc bug, I'll close it there.
Comment 10 Hans de Goede 2004-07-28 02:39:04 EDT
Changing component and assignee to xterm
Comment 11 Thomas E. Dickey 2004-07-28 06:02:31 EDT
For #128138, you don't have to patch the app-defaults file.
You can add this to the build line in the spec-file:
    --with-terminal-type=xterm-new
(modifying the app-defaults file always has the problem that it
interferes with user settings, while changing the compiled-in
default satisfies most people).
Comment 12 Thomas E. Dickey 2004-07-28 06:05:32 EDT
The comment in the spec-file regarding readonly files
(properly should have been forwarded as an upstream request
for a change in deliver process), is obsolete and the
corresponding text deleted.
Comment 13 Mike A. Harris 2005-02-08 00:39:50 EST
This issue should be fixed now in xterm-200 which is present in
rawhide.

Setting status to "RAWHIDE"


(P.S.  Thomas, I've replaced the comment in the spec file as well
 in 200-2 build.)