From owner-freebsd-current Sun Oct 20 10:27:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03105 for current-outgoing; Sun, 20 Oct 1996 10:27:35 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-89.rdcy01.pacbell.net [206.170.5.89]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03097 for ; Sun, 20 Oct 1996 10:27:30 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.6/8.7.3) with ESMTP id KAA17317; Sun, 20 Oct 1996 10:26:05 -0700 (PDT) Message-Id: <199610201726.KAA17317@precipice.shockwave.com> To: cracauer@wavehh.hanse.de cc: freebsd-current@freebsd.org Subject: Re: xterm termcap definition In-reply-to: Your message of "Sun, 20 Oct 1996 12:37:01 +0200." <9610201037.AA23601@wavehh.hanse.de> Date: Sun, 20 Oct 1996 10:26:05 -0700 From: Paul Traina Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: cracauer@wavehh.hanse.de (Martin Cracauer) Subject: Re: xterm termcap definition Paul Traina wrote: >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. I know, and I added km to our old entry as a stopgap for now. 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. The new xterm entry is 100% compatible with X11R6.1, the problem was that it appears to not be backwards compatible with older X11R6 entries. I tested pretty thoroughly on both a sun and a FreeBSD system and had no problems myself. Regarding the alternate screen behaviour: I think the "alternate screen" feature should *not* be enabled bu default, too many people are used to one-screen behaviour (i.e. the last screen of output of more/less is still displayed when more exits). Eric's and NetBSD's entries have alternate screen enabled and should be changes before importing them to FreeBSD. I aplogize for overlooking this. I disagree. The alternate screen behavior is the canonical behavior for XTerms. It's been freebsd that's been different all this time, and I recall just how much this torqed me off when I switched to freebsd. I am actually one who uses this feature, but I activate it on demand and think it should not be the default. This is not a new XFree option, it is present in all my xterms (the actual clients, not the termcap entries). AND, as one who uses alternate screen, I would really like to have such an entry already present in the termcap database under another name. See below. We may end up calling it xterm-new or something, given that it's xterm generic. 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. Right, and this is a bug in our more(1). We need to fix it, and we were lucky enough to find it with the new xterm entries. 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 :-) So, I actually ask for these commits: - Make the default Xterm entry one from Eric's database, alternate screens disabled. Not a bad idea, once we vette Eric's entry. - add an entry for TERM=xtermalt with the same contents as "xterm", but with alternate screen anabled. Let's see if we can fix the alternate screen behavior in FreeBSD's executables. I think we should move into the 90's. - add an entry for TERM=xfree to useXfree-xterm specific features, alternate screens disabled. - add the same entry as before, but with alternate screen enabled. TERM=xfreealt. No. More likely we may do one for X11R6.1, and only one of these. - rename the former FreeBSD entry instead of removing. You never can tell why people could want to revert to it. i.e. TERM=xtermold. Perhaps... I want to see how much it differs from the ancient entry before moving further along that particular path. - fix more/less so that the alternate screen is never used when the option is set to exit on the first EOF. But use the alternate screen when "exit on second EOF is hit", this is one of the things this option exists for, to be able to use "auto-exit" on terminals with an alternate screen. This suggested change will not alter behaviour on non-alternate-screen-enabled xterm termcap entries at all. Absolutely, some sort of similar fix should be used, however that fix may be more on the order of pausing at eof until a key is hit, so that alternate screen usage remains consistent. I have no idea if one of the committers will jump on my change requests - should they be considered useful - and just do it. Otherwise, I'll send PRs and this time include everything (diffs, termcap entries) that is needed (after testing it). I just don't want to waste my time, so please drop me a note when you want me to do one or more of the following: - send the new 5 termcap entries in tested form, with the behaviour listed above. - send diffs for more/less (after you made a decision whether my suggested behaviour makes sense). 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 present situation wasn't exactly what I demanded with my PR to update the xterm termcap entry. I'll be more precise in my next one, although I really couldn't forsee that some incompaible newer xterm exists and would be used. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer "As far as I'm concerned, if something is so complicated that you can't ex-" "plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin