I've recently upgraded xterm to version 191 in rawhide. Currently, the included xterm resources shipped are the stock upstream xterm resources with no additional Red Hat modifications. I've left our our customizations in order to determine which ones are still needed, and which ones we can eliminate.
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible. Run full screen text mode apps that use color, be sure to use emacs and other software that uses various keystrokes and combinations. Also use apps that use function keys, and if you use xterm over the network, be sure to test it's interactions over the network as well.
Particular things to look for: - Color changes - Backspace/Delete key changes of behaviour on standard Intel PC keyboard hardware (ie: the Backspace key should perform the standard PC backspace function of deleting the character to the left of the cursor, the DEL key should perform the standard PC DELETE function of deleting the character under the cursor) - Function key changes - Changes to 8-bit character handling, unicode, etc.
Please try to be as thorough as possible, so that I can resolve any regressions or inadvertent changes soon. If you've reported a bug in xterm before to us which was fixed in a future release, it is recommended that you please test for that bug again also.
My goal is to try to keep our xterm package as close to upstream as possible without causing major changes in behaviour from what existing users are used to from Red Hat supplied xterm. From time to time we need to make changes to compromise between differing expected behaviours, however we try to keep that minimal.
Please report back your testing results here to this mailing list, however if you discover bugs, also report them to our bugzilla.
Thanks in advance for testing xterm.
On Thu, 24 Jun 2004, Mike A. Harris wrote:
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible.
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
I still have the old xterms running - so I could compare..
Satish
On Thu, 24 Jun 2004, Satish Balay wrote:
On Thu, 24 Jun 2004, Mike A. Harris wrote:
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible.
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
I still have the old xterms running - so I could compare..
Same color shifts in emacs/pine.
And in 'emacs -nw' the status bar (or whatever) shows the filename in 'reverse colors' - with blue background with old xterm. With new xterm - the filename is just bold. I guss I like the new one better.
Satish
On Thu, 24 Jun 2004, Satish Balay wrote:
On Thu, 24 Jun 2004, Satish Balay wrote:
On Thu, 24 Jun 2004, Mike A. Harris wrote:
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible.
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
I still have the old xterms running - so I could compare..
Same color shifts in emacs/pine.
And in 'emacs -nw' the status bar (or whatever) shows the filename in 'reverse colors' - with blue background with old xterm. With new xterm
- the filename is just bold. I guss I like the new one better.
And is consistant with grapical emacs.
The same affect is noticed with tcsh and prompt 'set prompt="%B%m:%/>"'. Earlier, bold was somehow displayed as blue - now it is displayed correctly as bold.
Satish
On Thu, 24 Jun 2004, Satish Balay wrote:
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible.
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
I still have the old xterms running - so I could compare..
Same color shifts in emacs/pine.
And in 'emacs -nw' the status bar (or whatever) shows the filename in 'reverse colors' - with blue background with old xterm. With new xterm
- the filename is just bold. I guss I like the new one better.
Yeah, I believe bold, underline and italic should all look "correct" now, instead of emulated with color or reverse video. Wether that is desireable to everyone or not is another question, but it seems sane to me. ;o)
On Thu, 24 Jun 2004, Satish Balay wrote:
Date: Thu, 24 Jun 2004 13:12:06 -0500 (CDT) From: Satish Balay balay@fastmail.fm To: For testers of Fedora Core development releases fedora-test-list@redhat.com Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: For testers of Fedora Core development releases fedora-test-list@redhat.com X-BeenThere: fedora-test-list@redhat.com Subject: Re: Request for testing: xterm 191
On Thu, 24 Jun 2004, Mike A. Harris wrote:
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible.
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
I still have the old xterms running - so I could compare..
Yep, that's one of the changes. Upstream xterm's colors are slightly different from what Red Hat has shipped. I think they used to be very ugly or something, so we added customizations to make it prettier, then xterm cleaned itself up over time to look nicer, but with slightly different shade of blue. That's not fact, just personal hypothesis. ;o)
On Sun, Jun 27, 2004 at 03:24:39AM -0400, Mike A. Harris wrote:
Trying it on FC1 - The first thing I noticed is - the 'blue' color used by 'ls --color=auto' for 'dir' listings is different (a bit lighter shade. Not sure if this is a bug - but don't mind this new color.
Yep, that's one of the changes. Upstream xterm's colors are slightly different from what Red Hat has shipped. I think they used to be very ugly or something, so we added customizations to make it prettier, then xterm cleaned itself up over time to look nicer, but with slightly different shade of blue. That's not fact, just personal hypothesis. ;o)
Would it be possible to get the same shade of blue for gnome-terminal too? :-) :-) :-)
The thing is, color ls + gnome-terminal + white on black is useless since the default dark blue used for directories is nearly invisible. Of course if one knows the fix (making it lighter :-) ) everything is fine, and with a white background it's ok too.
Let me guess... "Upstream" :-)
On Thu, 24 Jun 2004 13:30:15 -0400 (EDT) "Mike A. Harris" mharris@redhat.com wrote:
I've recently upgraded xterm to version 191 in rawhide. Currently, the included xterm resources shipped are the stock upstream xterm resources with no additional Red Hat modifications. I've left our our customizations in order to determine which ones are still needed, and which ones we can eliminate.
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible. Run full screen text mode apps that use color, be sure to use emacs and other software that uses various keystrokes and combinations. Also use apps that use function keys, and if you use xterm over the network, be sure to test it's interactions over the network as well.
Particular things to look for:
- Color changes
- Backspace/Delete key changes of behaviour on standard Intel PC keyboard hardware (ie: the Backspace key should perform the standard PC backspace function of deleting the character to the left of the cursor, the DEL key should perform the standard PC DELETE function of deleting the character under the cursor)
- Function key changes
- Changes to 8-bit character handling, unicode, etc.
Please try to be as thorough as possible, so that I can resolve any regressions or inadvertent changes soon. If you've reported a bug in xterm before to us which was fixed in a future release, it is recommended that you please test for that bug again also.
My goal is to try to keep our xterm package as close to upstream as possible without causing major changes in behaviour from what existing users are used to from Red Hat supplied xterm. From time to time we need to make changes to compromise between differing expected behaviours, however we try to keep that minimal.
Please report back your testing results here to this mailing list, however if you discover bugs, also report them to our bugzilla.
Thanks in advance for testing xterm.
Hi Mike,
I know of one very irritating bug in the xterm with FC2: underscores are not displayed except on the last line (and they incorrectly stay there). This is 100% reproduceable on my setup. Looks like some off-by-one error somewhere.
Will check what conditions (font etc) are needed to get this problem and if it also happens on this new xterm, but I won't have time till somewhere next week or so.
greetings, Rob van Nieuwkerk
"Mike A. Harris" mharris@redhat.com writes:
[...]
If you are an xterm user using Fedora Core 1 or 2, please upgrade to this xterm release and test it as much as possible. Run full screen text mode apps that use color, be sure to use emacs and other software that uses various keystrokes and combinations. Also use apps that use function keys, and if you use xterm over the network, be sure to test it's interactions over the network as well.
- Backspace/Delete key changes of behaviour on standard Intel PC keyboard hardware (ie: the Backspace key should perform the standard PC backspace function of deleting the character to the left of the cursor, the DEL key should perform the standard PC DELETE function of deleting the character under the cursor)
Mike, I've just got to this thead and just did install new xterm. I left several running for comparison (version (179).
1) On first startup of emacs -nw I notice different behavior at backspace key. The old setup was to delete to the left of cursor
The new xterm with emacs -nw running, calls the help menu. (as if `C-h' had been pressed)
2) C-g in emacs is keyboard-quit. And I think would normally ring the bell. I have that set to `visual' so I see a momentary flash of the xterm. Very minor flash in old xterm (179)
New xterm (191) shows a very bigger/brighter flash. NOTE: ( To try reproducing) I have: *visualBell: true Set in ~/.Xresources. Then start xterm, start emacs -nw Press C-h Now press C-g to get the visual bell
3) The new color for directories already mentioned in this thread is a good improvement. I've run xterms in black for years and always had to change the bold blue of old because it nearly disappears in a black xterm. This new color of blue works well on a black xterm.
Mike A. Harris wrote:
Particular things to look for:
- Color changes
Another note of happiness with the new "light blue" colour. I find it a lot more usable as a light-on-dark type person. (I actually override all the colours, but this new one is a lot closer to what I normally use.)
One other issue though. In 179 (FC2) the 'colorBDMode' resource defaults to true, and in 191 it defaults to false. So previously you could set: xterm*colorBD: green and that just worked. Now it has no effect (bold characters are used rather than the colour).
Anyone explicitly setting the value of colorBDMode will get the same behaviour in both xterm versions. I don't imagine that many people change this anyway, and those who do should fairly easily be able to work out what's going on. I should note that it is particularly helpful that the xterm 191 manpage now lists default values for almost all resources. I don't regard this issue as a bug, just a default configuration change (just as might happen to sshd_config or anything else), and so would advise sticking with the 191/upstream settings.
Note: the same change and effect have happened to colorULMode/colorUL. I have not tested whether colorRVMode and colorBLMode (for reverse and blinking text respectively) have been affected.
PS: It seems (testing briefly on another machine via VNC - so I could be wrong) that bold/underline were previously blue/green respectively. Now they will appear bold/underline in the foreground text colour. I think this is a positive change as the latter will be most readable for a greater number of users. Most people will probably only notice the change when using man.
- Backspace/Delete key changes of behaviour on standard Intel PC keyboard hardware (ie: the Backspace key should perform the standard PC backspace function of deleting the character to the left of the cursor, the DEL key should perform the standard PC DELETE function of deleting the character under the cursor)
Backspace is broken when using `less` (^H is printed) - eg: when entering a search string. Delete works fine. I seem to be able to fix this with the follow resource:
xterm*VT100.Translations: #override <Key>BackSpace: string(0x7F)\n
Filed in bugzilla, number 126855.
- Function key changes
I can't send Alt+[0-9] through to irssi. The following fixes that for me: xterm*metaSendsEscape: true
Filed in bugzilla, number 126857.
HTH
Apologies for the second mail. Spotting another thing but then forgot about it until it annoyed me again just now. :)
Mike A. Harris wrote:
I've recently upgraded xterm to version 191 in rawhide. Currently, the included xterm resources shipped are the stock upstream xterm resources with no additional Red Hat modifications. I've left our our customizations in order to determine which ones are still needed, and which ones we can eliminate.
The saveLines X resouce (which determines the number of lines that have scrolled off-screen to be saved) now has a default of 64 (according to the manpage - a quick visual comparison says that's correct). This is far too short for me, and I would wager many developers.
I've no idea what it's set to in FC2, but that is certainly enough for my use. The last time I knowingly set a scrollback size was using PuTTY on a Windows system and ISTR I used about 1000-2000 lines. Will try a few values out over this week and see what I think's a good default.
The one big reason I can think of for keeping the scroll buffer size down is memory usage. Are there any others?
This isn't a bug per se, so I've not filed one. However, I'd be quite happy if this was changed to its FC2 value. On the other hand I'm OK setting my own value (there are enough other settings I change). What're other peoples' opinions on what the default value should be?
Cheers
-
Harry Putnam -
Mike A. Harris -
Mike A. Harris -
Pekka Pietikäinen -
Rob van Nieuwkerk -
Satish Balay -
Stuart Children