For some reason the old redhat-resources patch has been restored in the latest build, this causes a number of problems. Basicly the only 2 really needed and correct resources in the patch are: *VT100*backarrowKey: false *VT100*eightBitInput: false Besides that the following should be added: *ttyModes: erase ^? To make stty erase match the backspace key. I'll attach a resource patch with only these 3 resources with explanation. A full list of what is "wrong": -It contains the *VT100*backarrowKey: false resource, which is correct since we want xterm to send \177 for backspace (see bug 142659). But it doesn't contain the *ttyModes: erase ^? resource which causes the backspace key and stty erase to be a mismatch which causes problems for applications relying on terminal line-editing, such as less. -It contains wrong keybindings for the home and end keys, these bindings don't match terminfo nor gnome-terminal/konsole, the default bindings do match these. If this doesn't get fixed bug 122815 will be recreated all over again. -The keybindings mapping shift F1-F10 to F11-F20 are wrong, since now a days xterm has seperate esc-sequences for modified F-keys as part of the defaults -The del keybinding is not nescesarry since this is the default. -The mousewheel bindings are not nescesarry since these are built into xterm now a days. -The other changes are all cosmetical and change upstream defaults without any really good reason. AFAIK Fedora policy is to follow upstream as much as possible. If you choose to maintain the old patch the following changes _must_ be made to fix the noncosmetic issues listed above: Remove the complete *VT100.translations: resource and add the *ttyModes: erase ^? resource.
Created attachment 113460 [details] Minimal xterm-resources-redhat.patch fixing listed problems This patch only contains the really/minimal needed changes to the upstream resources file. It should be a drop in replacement for the current patch. Please fix this before FC4test3, aka freeze moment so that this will be fixed in FC4.
Thanks to the test3 slip this can still be fixed, a patch has been attached, please fix before test3 aka freeze.
Yes, the resource patch was intentionally restored, as it wasn't intended to have been missing for as long as we had it missing. It was temporarily disabled for a while, and due to lack of development time, got left disabled, thus reinstating various bugs that it previously fixed. After receiving numerous such reports, we have re-enabled an updated version of the patch. > Basicly the only 2 really needed and correct resources in the patch are: Depends on who you are, and what bugs you are experiencing and/or have reported to us. If you don't experience the bugs our local changes fix, then yes, it would seem the only needed changes are the ones that affect you. ;o) Unfortunately, there are as many people out there with different xterm configuration needs, as there are xterm users, and there can only be one single default - which isn't going to work for everyone the way they would like. There are indeed likely issues that need to be resolved, but I'm not going to make any major dramatic changes to xterm's resources at this point in the FC4 devel cycle. We definitely want to avoid a cat and mouse game of fixing one person's config request to create problems with another user's config, etc. ad infinitum - which is usually the case when xterm defaults are modified even just in thought. ;o) In short - I am *very* skeptical of changing anything at this point.
I understand that getting any of this fixed before FC4 is most likely not going to happen, still there are _real_ problems with the default config of xterm as currently shipped in Rawhide / FC4test. These problems are there because of changes in other places of FC for which xterm's resources should have been modified to match, but haven't. I'll try to explain all the problems one by one, most inmportant onces first. For now I would like to start with the top 2 problems: --- -It contains the *VT100*backarrowKey: false resource, which is correct since we want xterm to send \177 for backspace (see bug 142659). But it doesn't contain the *ttyModes: erase ^? resource which causes the backspace key and stty erase to be a mismatch which causes problems for applications relying on terminal line-editing, such as less. This problem/bug already existed in previous FC releases but didn't have any effects, because /etc/bashrc did a "stty erase `tput kbs`" which resulted in setting the erase char of the tty correctly. The fix is to add: *ttyModes: erase ^? This fix is 99.99% correct and save. --- -It contains wrong keybindings for the home and end keys, these bindings don't match terminfo nor gnome-terminal/konsole, the default bindings do match these. If this doesn't get fixed bug 122815 will be recreated all over again. RedHat used to modify xterm and clones to send ^[1~ for home instead of ^[[H, RedHat also used to ship a matching terminfo xterm entry. Somewere around FC1 the (right) decission was made to no longer do this (it has also been dropped from the debian keyb guidelines which were the source of this). The no longer modifying xterm and clones home sequence was afaik the reason to drop the redhat-resources patch. The same goes for end. The fix is to remove the home and end bindings from the keybindings mappings in the resource. --- Please concider fixing atleast these 2 problems for FC4, this will probably save you from bugreports about this once FC4 is released. Both bugs have been reported before against FC, and by other people as me. If you don't fix this you're recreating these bugs but then for xterm instead of for a clone. See bug 142659 abd bug 122815 for examples of previous reported similar problems.
In the default FC4 install, my backspace doesn't work in vim-minimal or vim-enhanced, in xterm. It works in KDE Konsole just fine. I am using the default xterm configuration inside the default KDE environment. No custom configuration here at all. Reproducible on both x86 and x86-64.
To fix vim, add *ttyModes: erase ^? to /usr/X11R6/lib{,64}/X11/app-defaults/XTerm
Mike Harris wrote "Depends on who you are, and what bugs you are experiencing and/or have reported to us" So far every single person I have talked to who has installed FC4 has got bug 160354 which is caused by this change. Acceptable fixes or workarounds have been sat in this bug and in bug 160354 for some time while Red Hat staff apparently just let it simmer. "there can only be one single default - which isn't going to work for everyone the way they would like." The default is now a broken xterm, if Mike or another employee wants to disagree please don't do so with hand waving about different people having different needs. xterm is real world software, let's hear real world problems. Overwhelmingly what I hear is "they broke xterm in FC4".
Mike Harris, is there a better way of fixing the obvious "BackSpace is broken with xterm in vi and man on vanilla FC4" problem? Or is there an obvious other situation that is improved by the current state of xterm in this regard?
Also seeing the problems described here - breaking backspace in vim.
Workaround for everybody needing a working xterm: Add xterm*VT100.translations: "" xterm*ttyModes: erase ^? to ~/.Xresources and relogin or "xrdb -merge .Xresources". Mike - which bugs did this patch fix? At least control sequences sent by xterm should match terminfo sequences for TERM=xterm. I just wanted to fill a bug report for mutt (not working home/end in xterm) caused by this. Besides - gnome-terminal also uses "TERM=xterm" and it sends correct home/end control sequences. If there are bugs in xterm which this patch fixes, there all should be also seen in gnome-terminal.
After some confusion I think that these settings are applied when a new xterm is started. Existing xterms will not start to work after xrdb merge.
(In reply to comment #3) > Unfortunately, there are as many people out there with different xterm > configuration needs, as there are xterm users, and there can only be one > single default - which isn't going to work for everyone the way they would > like. is there a list of what problems this patch fixes? To me it's hard to imagine that it's an acceptable situation that suddenly with FC4 the backspace key doesn't work in many console applications with xterm, due to this patch. Makes FC4 look bad IMO. Of course I edited my XTerm app-defaults by hand to fix the situation for myself. Does this patch really fix something for someone; is it really worth breaking so many text-mode apps under xterm? > In short - I am *very* skeptical of changing anything at this point. I hope it's clear that programming xterm to send a certain code for backspace and not having the xterm app-defaults align the stty mode to the same character is a bug. I hope it will get fixed before FC5 or before an RHEL version based on FC4 is made...
I've added the following to xterm-200-10 in rawhide: ! Bug fix for bug #155538 xterm*ttyModes: erase ^? Please upgrade to this release and test it, and provide feedback at your earliest convenience. Along with a few other fixes I've added to devel builds in the last while, if everything checks out ok, I am considering releasing an xterm-200 update for FC4 and FC3, and trying to resolve as many open xterm bugs as possible at the same time. Thanks everyone for testing, etc. Setting status to NEEDINFO_REPORTER and awaiting feedback on rawhide build.
*** Bug 160354 has been marked as a duplicate of this bug. ***
We need also a HOME/END keys send strings matching terminfo/termcap resorces. In terminfo man page we can read that "key_home" is referenced by "khome" in terminfo database and "kh" in termcap database. Also "key_end" is referenced by "kend" in terminfo and "@7" in termcap. Now, we can check what should be send by pressing keys "home" and "end" querying terminfo database: $ infocmp -1 | egrep khome\|kend kend=\EOF, khome=\EOH, Also in termcap database, /etc/termcap, in section "xterm|xterm terminal emulator (X Window System)" we can find: @7=\EOF kh=\EOH These are the strings which xterm sends by default - with no "translations" - and these are correct. But if we check what is sent by xterm, for example by command "cat" and pressing key home or end we get "\E[1~" or "\E[4~". "\E[1~" for key_home and "\E[4~" for key_end are strings send by console in "linux" terminal - in "early days" this was forced to be sent also by "xterm" - so applications which did not use terminfo/termcap but had these strings hardcoded worked. Also a lot of applications do have workarounds - interprete them even when they do not match terminal database strings (terminfo or termcap). There are workarounds for example in /etc/inputrc (for readline), /etc/joe/joerc (for joe editor). But "less", "mutt" and countless other do not have a workaround so home/end keys do not work in FC4 xterm. So: - backspace do work in vim - home/end do not work in "less", "mutt", "info", "pinfo", etc.
(In reply to comment #15) Please file a new bug report if you wish. People could keep adding new problems to this bug report probably forever. I prefer to consider each request as a separate issue, so that each can be closed individually. Thanks for confirming the backspace issue is now resolved. Setting status to "RAWHIDE".
Reopening, The home/end issue brought up again in comment 15 was also in the original report, so this is not adding new problems to this bug report forever. Basicly the entire resource patch is either wrong or purely cosmetical. Keeping the cosmetic parts is fine by me but the translation part is completly wrong, not only home/end but also the shifted function key stuff.
I've created new bug #169347: "home" and "end" keys in xterm generate wrong escape sequences
(In reply to comment #17) > Reopening, > > The home/end issue brought up again in comment 15 was also in the original > report, so this is not adding new problems to this bug report forever. Regardless, I'm treating this bug as the erase issue only. Bug reports should be one problem per report, so that once one thing is fixed, they can be closed. A separate bug was opened for the HOME/END issue, and if there are yet other issues, they should also be individual one-problem-per-bug report too. Otherwise we will likely select one of multiple issues in a bug report as "the" reported item, and ignore the others if they are different problems with different solutions. > Basicly the entire resource patch is either wrong or purely cosmetical. I'm perfectly happy removing the Red Hat patch and shipping xterm unmodified defaults. That will cause many users problems however, which yields no end of bug reports. > Keeping the cosmetic parts is fine by me but the translation part > is completly wrong, not only home/end but also the shifted function > key stuff. What is "cosmetic" to one user, is "critical feature" to another user however. A number of options there is no single setting that is 100% correct for all users, and some default must be chosen. In order to reduce differences from upstream xterm, I have removed the resource patch in previous OS release (FC3 and FC4 IIRC), and waited for end users to report bugs/problems that occured without our patch. Since then we have received that feedback and put the patch back, and fixed numerous new problems that have popped up. No matter what the defaults are, some user's setup out there doesn't work however, and they want us to change the default to what works for them, even if it breaks 10 other user's setups. IMHO, the only winning solution is to just ship upstream xterm unmodified, and point people to X.Org bugzilla when it doesn't work for them as they expect it to. Opinions?
I'm all for completly removing the resource patch. But there is one big BUT, it cannot be completly removed it should be replaced by a very small patch to make backspace send ASCII-DEL instead of CTRL-H, and to set stty accordingly. This has been discussed already in a 100 bugreports, so please reread those for the rationals. This is actually a RH/Fedora decission. I've tried numerous times to instead fix other terminal emulators which claim to be xterm todo as the real xterm does, but it was decided by RH that backspace should send ASCII-DEL on terminals which set $TERM to xterm. Besides that we have the also much discussed 8 bit input which breaks alt modified keys problem. So yes, please remove the patch (that was the initial/entire purpose of this bug) and replace it with one which adds the following 3 lines: *VT100*backarrowKey: false *ttyModes: erase ^? *VT100*eightBitInput: false AFAIK, this comes down to removing the translation part of the current patch and removing cosmetical stuff like colors, scrollbackbuffersize etc, which will never be right for anyone. Also (again AFAIK) any bugreports you received during the time that the patch was removed where either in ncurses/termcap, or where due to the above three lines not being present. If you know of any bugreport during the time that the patch was removed which is not cosmetical (font,color,scrollbackbuffersize) and was really in xterm, and not fixed by the three lines above, please give pointers, then I'll take a look.
From User-Agent: XML-RPC xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
<Sigh> xterm-206-1 from rawhide seems to have xterm-resources-redhat.patch completly disabled, which in itself is a good thing. But this introduces the following 2 bugs: -backspace now sends ^H and it was decided by the powers that be that the backspace key should send ASCII_DEL (\177) see bug 142659 for this decission. To fix this readd the following line to /usr/X11R6/lib/X11/app-defaults/XTerm: *VT100*backarrowKey: false -alt-key now sends the char with bit 7 set to one ( | 0x80) instead of sending esc-char. Causing for example alt-f and alt-b to go a word forward or backward on the cmdline in bash to fail. To fix this readd the following line to /usr/X11R6/lib/X11/app-defaults/XTerm: *VT100*eightBitInput: false Besides that it might be a good idea to readd: *ttyModes: erase ^? But that isnot needed now that termcap has the correct info. Adding this line however will make xterms behaviour independend of termcap.
Please note that the update completely breaks behaviour of alt+<any key> in the Midnight Commander what makes it unusable with xterm.
I have more side effects - less, more and man - all these do not process correctly the ^H as backspace (e.g. in search by /). So I fully agree with comment #22. This should be fixed asap.
Options I use with xterm-205-1.FC4 in .Xresources xterm*backarrowKeyIsErase: true xterm*metaSendsEscape: true mc all OK (it has a feature to check all used keys (F9->Options->learn Keys) note: disable alt-tab shortcut in window manager for completion to work bash, less, pinfo, vim, ne (the editor mentioned in bug #142659) backspace/delete, home/end, pgup/pgdown, arrows all OK mutt, info, lynx bs, home/end, pgup/pgdowm, arrows OK del not OK - I think bugs - kdch1 in terminfo is "\E[3~" which is sent by Delete so it should work
*** Bug 173654 has been marked as a duplicate of this bug. ***
Jindrich, if you duplicate bugs like this please CC me. Always interested to follow bugs that impact mc's behaviour (xterm, ncurses, slang, etc.) TIA.
This bug is now fixed with xterm-207-1.FC4, now submitted to Updates/Testing . The XTerm xresources modified by the redhat build are now only the bare minimum necessary for correct backspace operation, in /usr/lib/X11/app-defaults/XTerm : ' *VT100*eightBitInput: 0 *VT100*backarrowKey: 0 ' The default keyboard translations should be fine - XTerm should not have to modify them . The default xterm-207 xresources produce correct backspace operation under rawhide, where they are unmodified by the redhat xterm-207-6 build . This leads me to suspect that the backspace issue is actually a readline / xorg library bug. I was also puzzled by the way the 'Delete' key translation did not appear to work at all - the Delete, Home and End keys just produced an extra '~' char, and not the intended behavior. This was fixed for me by simply removing my ~/.inputrc (the readline configuration file), which had contained: ' set editing-mode emacs set history-preserve-point on set horizontal-scroll-mode off ' Once this ~/.inputrc was removed, the Delete, Home and End keys began working fine under xterm.
Jason, thanks for presenting the workaround for the correct delete key translation! I tried the rawhide xterm today with mc and it still mishandles the alt-key actions. Do you have any directions where the problem might be? The solution presented by Tomasz in comment #26 unfortunatelly doesn't work for me with xterm-207-6.
The fix in comment 26 wom't work because it should be XTerm* with capital X capital T, also it would be a better idea to use: "XTerm*VT100*eightBitInput: 0" And not "XTerm*metaSendsEscape: true" both should work and both have issues, but RedHat has been shipping xterm with "*VT100*eightBitInput: 0" for ages, so to get the element of least surprise that should be reactivated.
This is now fixed in rawhide xterm-207-7 by adding '*VT100*eightBitInput: 0' to the default /etc/X11/app-defaults/XTerm xresources file. This was NOT required to fix the backspace bug on Rawhide, but was required to fix the mc <ALT>+key problem. I've now tested mc-4.6.1a-0.23 on rawhide and it now responds to eg. <ALT>+? correctly when run in an xterm from 207-7 . xterm-207-1 in FC4 already had *VT100*eightBitInput: 0' .
Thanks, mc now handles the alt-key sequences without a problem since xterm-207-7.
jvdias wrote in comment #29: "The default xterm-207 xresources produce correct backspace operation under rawhide". I don't knwo how you came to this conclusion, but on both my x86_64 and my i386 rawhide install backspace is still broken in xterm. To reproduce: -start xterm -press CTRL-V -press backspace -result: "^H" -expected result "^?" aka ASCII-DEL aka \177 / 0177 To fix add: *VT100*backarrowKey: 0 To /etc/X11/app-defaults/XTerm p.s. /etc/X11/app-defaults/XTerm is a strange place, all other modular X11 stuff uses /usr/share/X11/app-defaults
/etc/X11/app-defaults is in rawhide not in FC4 update. I think moving this to etc is good idea as long as this will guarantee not to overwrite custom changes in these resource files. Or should /etc/X11/Xresources be used for custom modifications and app-defaults are meant as X11, well, default "config"?
All modular xorg apps have there app-defaults under /usr/share/X11/app-defaults, so that is where XTerm's should go. If you want to discuss changing the assigned directory for app-defaults, do so on fedora-devel mailinglist.
(In reply to comment #34) > > rawhide install backspace is still broken in xterm. > > To fix add: > *VT100*backarrowKey: 0 > To /etc/X11/app-defaults/XTerm > I could find no differnces between running with '*VT100*backarrowKey: 0' present or absent from app-defaults/XTerm . It is also settable from the <CTRL>+<LEFT MOUSE BUTTON> menu as the 'Backarrow (BS/DEL)' item. But, seeing as this was the default before, I've restored the '*VT100*backarrowKey: 0' setting in app-defaults/XTerm with xterm-207-8 . (In reply to comment #36) > All modular xorg apps have there app-defaults under /usr/share/X11/app-defaults, > so that is where XTerm's should go. Yes, that is were they were in Rawhide's xterm-206-1; but then, the new modular-X libraries were not looking for app-defaults in that location - now they are. Xterm's app-defaults directory is now in /usr/share/X11 with xterm-207-8, in rawhide-20051214 .
In reply to comment 37: > I could find no differnces between running with '*VT100*backarrowKey: 0' > present or absent from app-defaults/XTerm . It is also settable from the > <CTRL>+<LEFT MOUSE BUTTON> menu as the 'Backarrow (BS/DEL)' item. You tried the CTRL-V reproduction method I gave? Strange for me there is a difference. > But, seeing as this was the default before, I've restored the > '*VT100*backarrowKey: 0' setting in app-defaults/XTerm with xterm-207-8 . > Thanks!
Works beautifull now, closing with a resolution of rawhide.