Bug 155538 - PATCH: Old RedHat resource patch has been restored causing many problems
PATCH: Old RedHat resource patch has been restored causing many problems
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
https://bugzilla.redhat.com/bugzilla/...
:
: 160354 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-21 05:38 EDT by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-15 05:21:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Minimal xterm-resources-redhat.patch fixing listed problems (418 bytes, patch)
2005-04-21 05:42 EDT, Hans de Goede
no flags Details | Diff

  None (edit)
Description Hans de Goede 2005-04-21 05:38:53 EDT
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.
Comment 1 Hans de Goede 2005-04-21 05:42:09 EDT
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.
Comment 2 Hans de Goede 2005-05-06 18:57:57 EDT
Thanks to the test3 slip this can still be fixed, a patch has been attached,
please fix before test3 aka freeze.
Comment 3 Mike A. Harris 2005-05-24 12:39:43 EDT
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.
Comment 4 Hans de Goede 2005-05-24 14:09:03 EDT
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.
Comment 5 Jeff Garzik 2005-06-06 04:17:51 EDT
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.
Comment 6 Chris Ricker 2005-06-10 15:30:35 EDT
To fix vim, add

*ttyModes: erase ^?

to

/usr/X11R6/lib{,64}/X11/app-defaults/XTerm
Comment 7 Nick Lamb 2005-07-04 03:45:30 EDT
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".
Comment 8 Noa Resare 2005-07-07 16:20:50 EDT
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?
Comment 9 Michael Stevens 2005-07-08 07:14:07 EDT
Also seeing the problems described here - breaking backspace in vim.
Comment 10 Tomasz Ostrowski 2005-07-26 08:38:49 EDT
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.
Comment 11 Noa Resare 2005-07-26 08:58:04 EDT
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.
Comment 12 David Nichols 2005-08-04 12:23:48 EDT
(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...
Comment 13 Mike A. Harris 2005-09-24 06:28:47 EDT
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.
Comment 14 Mike A. Harris 2005-09-24 06:37:28 EDT
*** Bug 160354 has been marked as a duplicate of this bug. ***
Comment 15 Tomasz Ostrowski 2005-09-26 11:53:08 EDT
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.
Comment 16 Mike A. Harris 2005-09-26 12:47:56 EDT
(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".
Comment 17 Hans de Goede 2005-09-27 05:41:24 EDT
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.
Comment 18 Tomasz Ostrowski 2005-09-27 06:30:30 EDT
I've created new bug #169347:
"home" and "end" keys in xterm generate wrong escape sequences
Comment 19 Mike A. Harris 2005-09-27 20:29:17 EDT
(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?
Comment 20 Hans de Goede 2005-09-28 03:26:39 EDT
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.
Comment 21 Fedora Update System 2005-11-07 14:32:01 EST
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.
Comment 22 Hans de Goede 2005-11-13 08:08:38 EST
<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.
Comment 23 Fedora Update System 2005-11-14 13:02:33 EST
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.
Comment 24 Jindrich Novy 2005-11-19 02:01:40 EST
Please note that the update completely breaks behaviour of alt+<any key> in the
Midnight Commander what makes it unusable with xterm.
Comment 25 Adam Pribyl 2005-11-20 06:42:18 EST
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.
Comment 26 Tomasz Ostrowski 2005-11-21 09:47:25 EST
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
Comment 27 Jindrich Novy 2005-11-22 03:46:33 EST
*** Bug 173654 has been marked as a duplicate of this bug. ***
Comment 28 Leonard den Ottolander 2005-11-22 17:18:08 EST
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.
Comment 29 Jason Vas Dias 2005-11-22 19:14:00 EST
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.
Comment 30 Jindrich Novy 2005-11-23 07:50:10 EST
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.
Comment 31 Hans de Goede 2005-11-23 08:04:32 EST
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.
Comment 32 Jason Vas Dias 2005-11-23 13:15:58 EST
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' .
Comment 33 Jindrich Novy 2005-11-29 16:50:57 EST
Thanks, mc now handles the alt-key sequences without a problem since xterm-207-7.
Comment 34 Hans de Goede 2005-12-08 12:08:56 EST
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
Comment 35 Adam Pribyl 2005-12-13 13:20:52 EST
/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"? 
Comment 36 Hans de Goede 2005-12-14 02:49:53 EST
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.
Comment 37 Jason Vas Dias 2005-12-14 19:54:47 EST
(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 .
Comment 38 Hans de Goede 2005-12-15 02:13:55 EST
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!
Comment 39 Hans de Goede 2005-12-15 05:21:13 EST
Works beautifull now, closing with a resolution of rawhide.

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