Bug 128341 - redrawwing problem in xterm
Summary: redrawwing problem in xterm
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-21 22:14 UTC by Hans de Goede
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-02-08 05:39:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
specfile upped to version 194 and patch for bug 128138 added (4.53 KB, text/plain)
2004-07-28 06:33 UTC, Hans de Goede
no flags Details
patch fixing bug 128138 (405 bytes, patch)
2004-07-28 06:35 UTC, Hans de Goede
no flags Details | Diff

Description Hans de Goede 2004-07-21 22:14:35 UTC
-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 22:15:09 UTC
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 23:40:40 UTC
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 05:56:46 UTC
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 14:24:03 UTC
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 20:03:00 UTC
I have a fix for this, will make a patch today or tomorrow.

Comment 6 Thomas E. Dickey 2004-07-28 00:52:20 UTC
fix is committed in xterm patch #194.

Comment 7 Hans de Goede 2004-07-28 06:32:14 UTC
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 06:33:52 UTC
Created attachment 102242 [details]
specfile upped to version 194 and patch for bug 128138 added

Comment 9 Hans de Goede 2004-07-28 06:35:21 UTC
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 06:39:04 UTC
Changing component and assignee to xterm

Comment 11 Thomas E. Dickey 2004-07-28 10:02:31 UTC
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 10:05:32 UTC
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 05:39:50 UTC
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.)


Note You need to log in before you can comment on or make changes to this bug.