Bug 128138 - xterm should identify itself as xterm-new
xterm should identify itself as xterm-new
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-19 05:15 EDT by Hans de Goede
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 12:53:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
make xterm identify itself as xterm-new (361 bytes, patch)
2004-07-19 05:17 EDT, Hans de Goede
no flags Details | Diff
same as prev, and disable 8-bit input (402 bytes, patch)
2004-07-21 16:39 EDT, Hans de Goede
no flags Details | Diff
cleaned up, minimal xterm-resources-redhat.patch (394 bytes, patch)
2005-04-17 04:10 EDT, Hans de Goede
no flags Details | Diff

  None (edit)
Description Hans de Goede 2004-07-19 05:15:27 EDT
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.
Comment 1 Hans de Goede 2004-07-19 05:17:13 EDT
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,
Comment 2 Thomas E. Dickey 2004-07-19 05:23:06 EDT
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).
Comment 3 Hans de Goede 2004-07-21 16:35:11 EDT
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.
Comment 4 Hans de Goede 2004-07-21 16:39:50 EDT
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.
Comment 5 Thomas E. Dickey 2004-07-24 10:32:55 EDT
alternatively (to setting eightBitInput:false, would be to set
metaSendsEscape:true (but I believe either has problems).
Comment 6 Hans de Goede 2004-11-05 09:29:32 EST
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.
Comment 7 Hans de Goede 2005-02-23 10:28:33 EST
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.
Comment 8 Thomas E. Dickey 2005-02-23 11:05:53 EST
I didn't see any comment regarding metaSendsEscape (which
has fewer problems than setting eightBitInput false).
Comment 9 Hans de Goede 2005-03-08 13:53:29 EST
Either option is fine by me, its just that RH / FC shipped xterm used
to have eightBitInput set to false for a long while.
Comment 10 Mike A. Harris 2005-04-16 02:51:34 EDT
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"
Comment 11 Hans de Goede 2005-04-16 04:52:35 EDT
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.
Comment 12 Mike A. Harris 2005-04-16 06:40:49 EDT
Setting status to "RAWHIDE"

Comment 13 Hans de Goede 2005-04-16 11:38:10 EDT
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?
Comment 14 Mike A. Harris 2005-04-16 12:16:33 EDT
Hmm, this is very odd.

I will reopen the report until I can figure out what's happened to the
update...
Comment 15 Mike A. Harris 2005-04-16 12:53:58 EDT
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.
Comment 16 Hans de Goede 2005-04-17 04:08:09 EDT
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 ^?
Comment 17 Hans de Goede 2005-04-17 04:10:57 EDT
Created attachment 113283 [details]
cleaned up, minimal xterm-resources-redhat.patch
Comment 18 Thomas E. Dickey 2005-04-17 06:52:59 EDT
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).
Comment 19 Mike A. Harris 2005-04-19 08:41:35 EDT
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.
Comment 20 Thomas E. Dickey 2005-04-19 09:30:19 EDT
hmm - which was comment #19 directed to?
My comment in #18 was agreeing with comments #16 and #17.
Comment 21 Mike A. Harris 2005-04-19 10:25:45 EDT
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.


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