Bug 164210

iirc, gnuplot has a driver for this.

dann:  Sounds reasonable to me.  If we disable it in rawhide right now,
there is oodles of time for people to test rawhide prior to FC5 being
released.  If anyone out there uses tek terminal support and files a bug
report, we can always re-enable it before FC5 ships.

I'll update it in the next xterm build.

Added to xterm-200-8 in rawhide.

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.

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.

I use the Tek support occasionally, as does my father; it is one of the useful
features in xterm vs. most other terminal emulators.

If someone doesn't want Tek4014 support they can always use something else. 
Reducing the size of the binary should not be a primary goal at the cost of
features that aren't available in anything else.

Also, features should NOT be removed mid-stream.  If the decision to drop
Tek4014 support is made, it should only apply to future releases, not FC4.

(In reply to comment #6)
> I use the Tek support occasionally, as does my father; it is one of the useful
> features in xterm vs. most other terminal emulators.

Just curious, what do you use the Tek support for? Do you have a machine with
a Tektronix terminal? 

No, I don't have a true Tek terminal; that's why I use xterm's Tek4014 emulation
mode (just like people use xterm's VT102/VT220 emulation mode because they don't
have a standalone terminal).  I've got a VT102, but it is much nicer to use
xterm for most things.

Maybe there's a misunderstanding here: xterm emulates multiple terminal types. 
What most people use is the VT102/VT220 emulation mode.  There is also a Tek4014
emulation mode that is useful if you have programs that generate Tek4014 vector
graphics; they can be run in an xterm.  AFAIK there is no other Tek4014 emulator
available.

I occasionally use gnuplot with Tek4014 output instead of direct X11 output (it
can be easier to script).  My father (and a bunch of the people he works with)
uses a custom graphing program that has Tek4014 output as an option (but IIRC it
doesn't support X11).

There is still a bug here.  Either:

- you have removed functionality (tek4014 emulation) during a "stable" release

or

- you have removed functionality without fixing the spec file to document it
(the %description still says "and Tektronix 4014".

I still think that removing working functionality (that is not duplicated in any
other package that I am aware of) for the sole reason of slightly reducing the
binary size is a bad idea.  The only way to get tek4014 emulation under X is to
use xterm with it built in, so the only way this could even show up in Fedora
Extras is to take the xterm source RPM and rebuild it without --disable-tek4014
(but Extras packages aren't supposed to replace Core, so that wouldn't be allowed).

Ok, so it seems like some people do use tek support...  That seems like
a good reason to re-enable it IMHO, as people who don't need it can just
not use it, but people who do need it don't have it right now.

However... the xterm package baton has recently been passed on to
another developer...

reassigning...

OK, tek4014 mode is back, with xterm-207-2.FC4, and xterm-207-10 (FC-5).
You can build the SRPM with '--define _with_tek4014 0' to disable it again.

From User-Agent: XML-RPC

xterm-207-2.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.

From User-Agent: XML-RPC

xterm-207-2.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.

Yes, I see tek mode back.