After a lott of discussion it has been decided, that to work around xterm incompatibilities xterm emulators as gnome-term and konsole, should properly identify themself as being gnome and konsole. It also has been decided, that terminfo's plain xterm entry will represent xterm-r6 for best compatibility with whatever claims to be xterm. This means that using the real xterm, which identifies itself as just xterm, will result in a very poor user experience, since a lott will break, for example home and end keys, color support etc. This can be fixed by following the same philosophy as has been followed for gnome-term and konsole for xterm, make it properly identify itself as being the latest greatest xterm and thus set TERM to xterm-new. I'll attach a patch to the XTerm appdefaults file which makes xterm identify itself as xterm-new. Please understand that this is a vital patch, without it xterm users will have a very bad experience in FC3.
Created attachment 102026 [details] make xterm identify itself as xterm-new See bug 122815 for the discussion where all the decissions I'm talking about have been made,
That's what I've been doing on my machine recently (though of course "xterm" is aliased to "xterm-new" - a logical consequence of the release of X11R6.7).
I noticed all other modifications to XTerm's app-defaults are gone. For the keybindings this is a good thing, since they we're wrong for a while now. For the bold and underline color stuff one can argue, but keeping it at the upstream defaults seems good. However the removal of: *eightBitInput: false Makes alt+f and alt+b to skip through words on the bash-prompt fail, and probably also causes other problems. So I would like to suggest adding this again, see my next patch.
Created attachment 102117 [details] same as prev, and disable 8-bit input Also see bug 49315, atleast according to the old appdefaults patch, I can't access that bug, GRRRR.
alternatively (to setting eightBitInput:false, would be to set metaSendsEscape:true (but I believe either has problems).
Although this bug status is new, it seems that someone has merged my second patch. Unfortunatly the reason for the first part of this patch making xterm identify itself as xterm-new is no longer valid. The idea behind this was that each terminal (gnome-terminal, konsole, xterm) would identify itself more exactly then just "xterm", so that each could have an optimised terminfo entry and then reserve the generic xterm terminfo name for a compatibility entry with only basic functionality. This was decided as a result of discussions around bug 122815. But later on it was decided not to go this way. So now the xterm terminfo name properly describes xterm and having xterm identify itself as xterm-new is counter productive since there are systems out there without an xterm-new terminfo/termcap entry. The second part of the patch, fixing bug 49315 needs to stay though.
The current rawhide xterm still misses the: *eightBitInput: false Line, which makes alt+f and alt+b to skip through words on the bash-prompt fail, and probably also causes other problems, this is also related to bug 49315, which I don't have permission to see. The original reason for this bug is mute though lett me know if you want it closed and want a new bug for this.
I didn't see any comment regarding metaSendsEscape (which has fewer problems than setting eightBitInput false).
Either option is fine by me, its just that RH / FC shipped xterm used to have eightBitInput set to false for a long while.
Our current rawhide xterm resources patch has been updated for a while now, and contains the following: +! Bug fix for bugzilla bug #49315 +*VT100*eightBitInput: false Setting status to "RAWHIDE"
1) The status is still set to asigned, once I've checked this is indeed in rawhide, I'll close it myself. I'm currently upgrading my complete system from FC3 -> rawhide, but that will take a while on a 1mbit link :) 2) While we're on the subject of xterm and friends could you also please take a look at bug 142659. This bug is about xterm sending CTRL-H for backspace, which is what terminfo claims it should, but konsole and gnome-temrinal sending ASCII-DEL (\177). Since I haven't had any response on this sofar I've gone ahead and assumed that what the upstream real xterm and ncurses say it should be is correct. This has resulted in a patch for konsole which is now in rawhide & test2 and is awaiting merging upstream. So now only gnome-terminal sends ASCII-DEL for backspace. Once my system is upgraded to rawhide I'll take a look at cooking up a patch which makes gnome-temrinal also send CTRL-H for backspace and set stty erase correctly.
Setting status to "RAWHIDE"
Erm, I've just completed a complete yum update to rawhide (several things are broken, but that's unrelated) and the folliwng lines: ! Bug fix for bugzilla bug #49315 *VT100*eightBitInput: false Are NOT present in: /usr/X11R6/lib/X11/app-defaults/XTerm Reopen or new bug?
Hmm, this is very odd. I will reopen the report until I can figure out what's happened to the update...
Ok, I discovered the problem.... A few weeks ago I had applied a patch to my local checkout to update xterm, and checked it into CVS, but my build failed due to a transient failure in the buildsystem. I missed the failure notification somehow and didn't build a new package. ;o) I've rebuilt xterm as xterm-200-6 in rawhide with the changes integrated now. Please test again, and reopen if the problem returns. Thanks. Setting status back to "RAWHIDE" for new build.
As a result of our discussion in bug 142659 I've taken a look at xterm-200-6 (from CVS, not in rawhide yet). And I noticed that you've reapplied the complete old xterm-resources-redhat.patch. AFAIK, that was not the intention, the idea was to only add those changes wich we're really nescesarry to fix behaviour, and not the cosmetic ones like bold/underline colors, bigger scrollback, mouse wheel bindings, etc. Also this old patch changes the ESC-sequences send by home and end to the old ones (^[[1~ and ^[[4~) recreating/reopening bug 122815 . I've "created" a patch which only adds the minimal needed changes: -make backspace send ASCII-DEL and set stty erase accordingly -make alt + key send ESC-key instead of 8bit chars. If you really want to use the full old-patch the following changes are nescesarry: -remove the keybindings for home/end (they're wrong) -remove the keybindings for shifted Function-keys (wrong again) -remove the keybinding for del (this is the default now a days) -add the follwowing line (this sets stty erase correctly): *ttyModes: erase ^?
Created attachment 113283 [details] cleaned up, minimal xterm-resources-redhat.patch
mouse wheel bindings have been part of xterm's default translations for a while (and were part of its resource file longer). The changes to translations resource in Redhat's patch (generally) were unnecessary (and should be removed from any future package).
Please open a new bug report against xterm, for any new issues so that we can track them separately and close each individual issue as they're addressed. Thanks in advance.
hmm - which was comment #19 directed to? My comment in #18 was agreeing with comments #16 and #17.
sorry... comment #19 was in response to comment #16 and #17. They are unrelated to what this bug was filed about, and this bug is now closed. Tracking new requests attached onto existing bug reports which are closed doesn't work very well. ;o) Next time I am scanning for xterm issues to investigate, I will not find random comments/suggestions added to a closed bug, as I don't look at closed bugs when looking for new work to do, as they're well.... closed. ;o) Feel free to open new bugs to track new requests though, and one of us will review them next time we're updating xterm. Thanks guys.