Date: Sun, 20 Oct 1996 22:02:25 +1000 (EST) From: David Dawes <dawes@rf900.physics.usyd.edu.au> To: cracauer@wavehh.hanse.de Cc: pst@freefall.freebsd.org, freebsd-current@FreeBSD.org Subject: Re: xterm termcap definition Message-ID: <199610201202.WAA07479@rf900.physics.usyd.edu.au> In-Reply-To: <9610201037.AA23601@wavehh.hanse.de> from "Martin Cracauer" at Oct 20, 96 12:37:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>>Some folks are complaining about the behavior of the nexw xterm definition.
>>I've restored us to the ANCIENT X1 0 compatible xterm definition we had
>>a week ago. until we get to ghehthe bottom of things, then I'll move us forward
>>to the X11R6 compatible definition again. :-(
>
>As the one who originated a PR to update the xterm entry in termcap
>(to be able to use the Meta key in emacs), let me quote from the PR
>that Eric Raymond's entries from his termcap database are a better
>choice that newest XFree entries, at least they are tested with a wide
>range of xterms. And they enable the Meta key. FreeBSD badly needs a
>new entry, but the XFree entry is the worst choice. Look at NetBSD,
>they have Eric's entry (didn't check for additions, though) and things
>work fine. Using the Meta key doesn't need new XFree features.
>
>Having an XFree entry with the new options as TERM=xfree or xfreeterm
>or something like it would make sense, although I have no idea how
>people should tell that such an option is availiable. Really, I have
>now Idea how they could be so ignorant to add their extensions to the
>default xterm entry (where they?). They need a new name for their
>xterm to identify itself and then match it in a new termcap
>entry. That way, things will no longer work when logging in from a new
>xterm to a box without the new termcap entry, but I think that is the
>smaller evil compared to misbehaviour everytime someone loggs in from
>an old xterm to a XFree box.
Firstly, xterm is not static. Its capabilities and the official X
Consortium termcap entry have changed over time, without any name change.
I suppose the name should change every time something new is added, but
that causes problems for people too.
>IN additional to the unusual behaviour of alternate screen, things in
>FreeBSD are even worse. More's default behaviour is to exit immediatly
>when EOF is hit, so people don't have a chance to see the last page
>when an alternate screen is availiable. One could call it is bug in
>more/less that is alternate screen is used at all when the option to
>exit on the first EOF is set. While I think this should be fixed in
>FreeBSD's more sources (so that end-on-eof enabled more *never* uses
>the second screen), I still think the default xterm shouldn't use an
>alternate screen. Just for people how use an alternate screen (like I
>do sometimes), less should behave in a way that one can see the last
>page :-)
Yes, I'd like to see the behaviour of more changed. A problem is that
xterm's alternate screen function isn't set using any 'enable/disable
alternate screen' termcap function (I don't think there is one), but
with ti/te:
te str String to end programs that use termcap.
ti str String to begin programs that use termcap.
>One should get in contact with XFree to discuss things. Do they realy
>have a default xterm termcap entry that doesn't work when logged in
>from non-Xfree xterms? I can't beleive it. Do they feel they're alone
>in the world (Could drop a nasty comment about Linux here)? Is there
>some XFree hacker on this list?
The 'xterm' termcap we (XFree86) have does make use of our xterm
enhancements. With 3.2, it will also include an xterm-r6 entry which
is the standard X Consortium termcap entry from X11R6, and an xterm-r5
entry from X11R5. However, none of the entries from our termcap file
get put into /etc/termcap without the installer explicitly editing
/etc/termcap themselves, so this isn't forced on anyone. The postinst.sh
XFree86 script mentions this, and warns about the incompatibility.
David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610201202.WAA07479>