From owner-freebsd-bugs Wed Nov 17 19:10: 4 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 8637B14EEB for ; Wed, 17 Nov 1999 19:10:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id TAA79657; Wed, 17 Nov 1999 19:10:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Wed, 17 Nov 1999 19:10:01 -0800 (PST) Message-Id: <199911180310.TAA79657@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Ronald F. Guilmette" Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) Reply-To: "Ronald F. Guilmette" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/14959; it has been noted by GNATS. From: "Ronald F. Guilmette" To: "Matthew D. Fuller" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) Date: Wed, 17 Nov 1999 19:06:33 -0800 I learned something today. After some fiddling, I finally managed to get a ``nice'' value for the xterm capabilities into my TERMCAP environment variable, and then, as expected, vi started to work the way I like it to work. But then I got a rude shock the very next time I tried to use `more' command. *It* started restoring the prior screen contents each time it exited also! Yes, I read the comments in: http://www.freebsd.org/cgi/getmsg.cgi?fetch=317685+320827+/usr/local/www/db/text/1998/freebsd-current/19981101.freebsd-current so I knew that `more' would try to do this, but the above article seemed to indicated that giving `more' a -e option would stop it from doing this. Well, it didn't actually stop it. It just slowed it down a little. But `more' was still restoring the prior screen contents whenever it finally exited. Yecch! Gag! This was most annoying, and wasn't what I had in mind at all! I think that I understand better now the difference in opinion between myself and others relative to the ``correct'' contents of the xterm termcap entry. I still feel that the screen save/restore behavior (when using vi, at least) is what most people would want, if given a clear choice, and a chance to vote on it, but I *do* quite definitely agree that having this behavior show up when using `more' is perfectly awful and hidious, and it seems to me that nobody could possibly want this (screen save/restore) behavior when using the `more' command. It now appears to me that the primary motivation for taking the save/restore stuff out of the xterm termcap entry might have related more to the misuse of these capabilities (by `more') as opposed to their effect when used by `vi'. I didn't grasp that until now because I have never before been afflicted with/by an incarnation of the `more' command that tried to do screen restoring upon exit (and it still seem quite odd to me that `more' should even try to do this). Given what I now know about the behavior of `more', it now seems clearer to me that ever that the Right Solution for this unfortnate situation is to leave the screen save/restore capability in the termcap database and then to merely add command options to programs (e.g. vi, more, etc) that would say, in effect ``Don't do that!'' I myself would be very glad to have exactly such an option for the `more' command. (In the meantime, I've kludged together something local here... a wrapper shell script for `more' that *removes* the te=/ti= stuff from the TERMCAP environment variable before starting `more'... but that's kind-of an ugly hack.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message