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.