From rfg@monkeys.com Wed Nov 17 12:56:15 1999
Return-Path: <rfg@monkeys.com>
Received: from monkeys.com (i180.value.net [206.14.136.180])
	by hub.freebsd.org (Postfix) with ESMTP id 8831914D97
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 17 Nov 1999 12:56:12 -0800 (PST)
	(envelope-from rfg@monkeys.com)
Received: (from rfg@localhost)
	by monkeys.com (8.9.3/8.9.3) id MAA04664;
	Wed, 17 Nov 1999 12:56:07 -0800 (PST)
Message-Id: <199911172056.MAA04664@monkeys.com>
Date: Wed, 17 Nov 1999 12:56:07 -0800 (PST)
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Reply-To: rfg@monkeys.com (Ronald F. Guilmette)
To: FreeBSD-gnats-submit@freebsd.org
Cc: Stephen Roome <steve@visint.co.uk>,
	John Polstra <jdp@polstra.com>, jkh@FreeBSD.ORG
Subject: incomplete xterm termcap entry (see also bug gnu/5039)
X-Send-Pr-Version: 3.2

>Number:         14959
>Category:       misc
>Synopsis:       incomplete xterm termcap entry (see also bug gnu/5039)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 17 13:00:02 PST 1999
>Closed-Date:    Thu Nov 18 02:33:06 PST 1999
>Last-Modified:  Thu Nov 18 02:33:37 PST 1999
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
E-Scrub Technoligies, Inc.
>Environment:

	xterm window running on whatever version of XFree86 comes with 3.3

>Description:

	When running (n)vi in an xterm window, (n)vi should save the current
	xterm window contents on startup and then restore the old xterm
	contentx upon exit (or backgrounding).  But it doesn't.

	I believe that this is actually due to some incompletness in the
	stock termcap entry for `xterm' hat is being distributed with FreeBSD
	3.3.

	(See also bug gnu/5039 which may or may not be related.)

>How-To-Repeat:

	Start up vi (on any file) and then exit vi.
	Note that the old xterm window contents are not restored.

>Fix:

	I wish I knew.

	I fixed this same *&^%$# problem about ten centuries ago in the
	terminfo entry for `xterm' on my old Linux system, but I'll be
	damned if I can find any old notes about how I did that now.
	
	


>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: rfg@monkeys.com (Ronald F. Guilmette)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039)
Date: Wed, 17 Nov 1999 16:05:11 -0500 (EST)

 <<On Wed, 17 Nov 1999 12:56:07 -0800 (PST), "Ronald F. Guilmette" <rfg@monkeys.com> said:
 
 > 	When running (n)vi in an xterm window, (n)vi should save the current
 > 	xterm window contents on startup and then restore the old xterm
 > 	contentx upon exit (or backgrounding).  But it doesn't.
 
 That is a matter of taste.  You are free to use an alternate termcap
 entry for xterm if this obnoxious behavior pleases you.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
 

From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039)
Date: Wed, 17 Nov 1999 15:23:21 -0600

 [Cc's trimmed]
 
 On Wed, Nov 17, 1999 at 12:56:07PM -0800, a little birdie told me
 that Ronald F. Guilmette remarked
 > 
 > 	When running (n)vi in an xterm window, (n)vi should save the current
 > 	xterm window contents on startup and then restore the old xterm
 > 	contentx upon exit (or backgrounding).  But it doesn't.
 
 This was discussed a few months back (on -hackers, maybe?  Don't quite
 remember...), and the prevailing opinion was that most people PREFERED
 the FreeBSD behavior.  I certainly do; if I ^Z vi while I'm working I
 want to still be able to see the contents of it, among other things.
 
 It was a single termcap property though, IIRC.  I'll see if I can't dig
 it out of my archives...
 
 
 
 
 -- 
 Matthew Fuller     (MF4839)     |    fullermd@over-yonder.net
 Unix Systems Administrator      |    fullermd@futuresouth.com
 Specializing in FreeBSD         |    http://www.over-yonder.net/
 FutureSouth Communications      |    ISPHelp ISP Consulting
 
 "The only reason I'm burning my candle at both ends, is because I
       haven't figured out how to light the middle yet"
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) 
Date: Wed, 17 Nov 1999 13:24:00 -0800

 In message <199911172105.QAA21588@khavrinen.lcs.mit.edu>, you wrote:
 
 ><<On Wed, 17 Nov 1999 12:56:07 -0800 (PST), "Ronald F. Guilmette" <rfg@monkeys
 >.com> said:
 >
 >> 	When running (n)vi in an xterm window, (n)vi should save the current
 >> 	xterm window contents on startup and then restore the old xterm
 >> 	contentx upon exit (or backgrounding).  But it doesn't.
 >
 >That is a matter of taste.  You are free to use an alternate termcap
 >entry for xterm if this obnoxious behavior pleases you.
 
 IN MY OPINION, the people who DO NOT want to have the screen restored when
 exiting vi/nvi are the ones who should be ``free to use an alternate termcap
 entry for xterm if THAT obnoxious behavior pleases them''.
 
 Regardless of who is ``correct'' with regards to this specific bit of vi/nvi
 behavior, the bottom line, as far as I'm concerned, is that people who hold
 the view that vi/nvi should NOT restore the screen upon exit/backgrounding
 should, ideally, have their desires satisfied by vi itself... perhaps via
 some new vi command line option... NOT by intentionally hobbling the xterm
 termcap entry as a back-door way of sabotoging the functionality which vi
 would (and does) otherwise exhibit for all terminals that have the capability
 of saving and restoring an entire screen full of stuff.
 
 If vi does stuff you don't like, then change vi.  But the termcap entry for
 xterm (or for any other type of terminal) should be an _accurate_ and also
 a _complete_ representation of _all_ of that terminal's significant capabil-
 ities.  After all, it ain't just vi that uses those termcap entries.
 

From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039)
Date: Wed, 17 Nov 1999 15:36:04 -0600

 On Wed, Nov 17, 1999 at 01:30:02PM -0800, a little birdie told me
 that Matthew D. Fuller remarked
 >  
 >  It was a single termcap property though, IIRC.  I'll see if I can't dig
 >  it out of my archives...
 
 And here it is.
 On the -current mailing list around Nov 2 1998, in the thread "screen not
 restored on exit of (less|more|vi|.*)"  (check the archives).
 
 The relevant termcap properties are te and ti, and several solutions are
 given in the thread (including using the 'xterm' termcap entry from
 XFree86 after fixing a bug in it).  See the following entry from Mike
 Smith:
 
 > It is indeed the te/ti escapes.  I don't know what you've done, but it
 > was decided by many people that the use of te/ti was basically ugly
 > (and it has some bad associated bugs) so it was disabled.
 
 
 
 
 -- 
 Matthew Fuller     (MF4839)     |    fullermd@over-yonder.net
 Unix Systems Administrator      |    fullermd@futuresouth.com
 Specializing in FreeBSD         |    http://www.over-yonder.net/
 FutureSouth Communications      |    ISPHelp ISP Consulting
 
 "The only reason I'm burning my candle at both ends, is because I
       haven't figured out how to light the middle yet"
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: "Matthew D. Fuller" <fullermd@futuresouth.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) 
Date: Wed, 17 Nov 1999 13:43:04 -0800

 In message <19991117152321.O17332@futuresouth.com>, you wrote:
 
 >[Cc's trimmed]
 >
 >On Wed, Nov 17, 1999 at 12:56:07PM -0800, a little birdie told me
 >that Ronald F. Guilmette remarked
 >> 
 >> 	When running (n)vi in an xterm window, (n)vi should save the current
 >> 	xterm window contents on startup and then restore the old xterm
 >> 	contentx upon exit (or backgrounding).  But it doesn't.
 >
 >This was discussed a few months back (on -hackers, maybe?  Don't quite
 >remember...), and the prevailing opinion was that most people PREFERED
 >the FreeBSD behavior.  I certainly do; if I ^Z vi while I'm working I
 >want to still be able to see the contents of it, among other things.
 
 As I mentioned in response to another fellow who said (basically) the
 same thing as you just said, if you want vi to behave in a certain
 way, then fine.  Hack vi until it behaves the way you want.  (Perhaps
 vi should have a command line option that would enable or disable the
 screen save/restore behavior... one that would apply to *ALL* terminal
 types that have this capability.)  But please do not cripple _my_ xterm
 termcap entry just because _you_ don't like what one particular system
 utility program is doing with that complete and accurate (termcap) infor-
 mation.
 
 The termcap entry for a given terminal type should be as complete and
 accurate as possible because it is there for the benefit of _all_ of
 the programs that use the termcap database.  Deleting perfectly correct
 capability descriptions from termcap entries as an indirect way of
 ``dumbing down'' certain specific programs (until those specific programs
 are dumb enough to suit the tastes of some portion of the user base) doesn't
 seem at all kosher to me.
 
 Let termcap be termcap!  If you don't like vi, then fix vi.
 
 >It was a single termcap property though, IIRC.  I'll see if I can't dig
 >it out of my archives...
 
 Thank you.  I would appreciate it.  (I *really* want the necessary termcap
 additions to make this work ``right''.)
 
 

From: "Matthew D. Fuller" <fullermd@futuresouth.com>
To: "Ronald F. Guilmette" <rfg@monkeys.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039)
Date: Wed, 17 Nov 1999 15:56:27 -0600

 On Wed, Nov 17, 1999 at 01:43:04PM -0800, a little birdie told me
 that Ronald F. Guilmette remarked
 > 
 > As I mentioned in response to another fellow who said (basically) the
 > same thing as you just said, if you want vi to behave in a certain
 > way, then fine.  Hack vi until it behaves the way you want.  (Perhaps
 > vi should have a command line option that would enable or disable the
 > screen save/restore behavior... one that would apply to *ALL* terminal
 > types that have this capability.)  But please do not cripple _my_ xterm
 > termcap entry just because _you_ don't like what one particular system
 > utility program is doing with that complete and accurate (termcap) infor-
 > mation.
 
 It's not just vi.  I prefer that with *ALL* full-screen applications.  I
 remember flipping out the first time I saw the 'restore' behavior and
 hating it instantly.  I want to (for instance) more(1) or less(1) through
 a file until I see the info I want, exit more, and then still be able to
 see the information to do whatever I wanted to do with it.
 
 
 > The termcap entry for a given terminal type should be as complete and
 > accurate as possible because it is there for the benefit of _all_ of
 > the programs that use the termcap database.  Deleting perfectly correct
 > capability descriptions from termcap entries as an indirect way of
 > ``dumbing down'' certain specific programs (until those specific programs
 > are dumb enough to suit the tastes of some portion of the user base) doesn't
 > seem at all kosher to me.
 
 I take severe offense at this, even though I'm sure you didn't mean it
 the way it sounded.
 
 
 > Let termcap be termcap!  If you don't like vi, then fix vi.
 
 But it's not just vi!
 A lot of people don't like that termcap property, so we fixed it   :-)
 
 
 > Thank you.  I would appreciate it.  (I *really* want the necessary termcap
 > additions to make this work ``right''.)
 
 See my previous message, and the thread referenced in the archives.  The
 thread will give you all the background info, as well as several
 solutions.
 
 
 Overall (as a side commentary), I think you're taking a far too
 aggressive position in defense of this.  When things are done, not done,
 undone, or medium well done in FreeBSD, it tends to be by knowledgable
 people for good reason; if things are badly considered, the developers
 and community have never shown ANY reluctance to let it be know very very
 very loudly.  The fact that it's been this way for this long means that
 as a general rule, everybody agrees with it, and you'd probably get a bit
 less heat directed at you than I've seen in just a few responses if you
 had said 'Why is this done this why' instead of 'Why isn't this done the
 RIGHT way, like this'.
 
 We're all flame-happy enough already, without someone taking an agressive
 posture over an issue that's been hashed out several times before (even
 if they didn't know that).  Ask me sometime about what happened when I
 innocently proposed moving vi to /bin   ;>
 
 
 
 -- 
 Matthew Fuller     (MF4839)     |    fullermd@over-yonder.net
 Unix Systems Administrator      |    fullermd@futuresouth.com
 Specializing in FreeBSD         |    http://www.over-yonder.net/
 FutureSouth Communications      |    ISPHelp ISP Consulting
 
 "The only reason I'm burning my candle at both ends, is because I
       haven't figured out how to light the middle yet"
 
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: "Matthew D. Fuller" <fullermd@futuresouth.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) 
Date: Wed, 17 Nov 1999 14:47:32 -0800

 In message <19991117155627.R17332@futuresouth.com>, you wrote:
 
 >On Wed, Nov 17, 1999 at 01:43:04PM -0800, a little birdie told me
 >that Ronald F. Guilmette remarked
 >> 
 >> As I mentioned in response to another fellow who said (basically) the
 >> same thing as you just said, if you want vi to behave in a certain
 >> way, then fine.  Hack vi until it behaves the way you want.  (Perhaps
 >> vi should have a command line option that would enable or disable the
 >> screen save/restore behavior... one that would apply to *ALL* terminal
 >> types that have this capability.)  But please do not cripple _my_ xterm
 >> termcap entry just because _you_ don't like what one particular system
 >> utility program is doing with that complete and accurate (termcap) infor-
 >> mation.
 >
 >It's not just vi.  I prefer that with *ALL* full-screen applications.
 
 OK.  Then you should go and make the rounds and talk with ALL of the
 maintainers of those programs and tell them all to add options that will
 allow you to _disable_ the screen save/restore capabilities which their
 authors labored to produce.
 
 >I remember flipping out the first time I saw the 'restore' behavior and
 >hating it instantly.  I want to (for instance) more(1) or less(1) through
 >a file until I see the info I want, exit more, and then still be able to
 >see the information to do whatever I wanted to do with it.
 
 Right.  I understand.  And I want it the other way.
 
 >> The termcap entry for a given terminal type should be as complete and
 >> accurate as possible because it is there for the benefit of _all_ of
 >> the programs that use the termcap database.  Deleting perfectly correct
 >> capability descriptions from termcap entries as an indirect way of
 >> ``dumbing down'' certain specific programs (until those specific programs
 >> are dumb enough to suit the tastes of some portion of the user base) doesn't
 >> seem at all kosher to me.
 >
 >I take severe offense at this, even though I'm sure you didn't mean it
 >the way it sounded.
 
 I did not mean to offend, no.
 
 I just selected the best words to communicate what I mean.  After all, what
 is the term that _you_ would use to describe the _removal_ of features and/or
 the _disbling_ of features from a product or package?  Isn't that traditionally
 referred to as a ``dumbing down'' process?
 
 There is nothing wrong with wanting a ``dumbed down'' version of some particu-
 lar package or utility, and I apologize if I made it sound in any way as if
 anyone who wanted that were himself/herself "dumb".  I certainly did not
 mean to imply *that*!  (I used a ``dumb'' terminal for many years back in
 the 70's but I always felt that I myself was pretty smart while I was doing
 it. :-)
 
 But the fact remains that what we are talking about here is the intentional
 _disabling_ of capabilities that vi was in fact laboriously programmed to
 have.  And although that may indeed suit the tests of some, it is merely
 a LOSS of functionality to others.
 
 >> Let termcap be termcap!  If you don't like vi, then fix vi.
 >
 >But it's not just vi!
 >A lot of people don't like that termcap property, so we fixed it   :-)
 
 Ummm.... are you also going to remove the capability from xterm itself,
 and also from any other terminals out there on the market that have this
 same sort of save/restore feature/capability?
 
 Well, anyway, did anyone do a diligent search of the entire termcap database,
 looking for other ti=/te= entries that might cause save/restrore behavior
 with OTHER terminal types?  And did someone elide all of those also??
 
 >Overall (as a side commentary), I think you're taking a far too
 >aggressive position in defense of this.
 
 Sorry.  I just do not like the thought of perfectly good features which
 more than a few programmers (not the least of whom being the author of
 nvi _and_ the author of xterm) have labored long and hard to implement
 being chucked overboard like so much excess ballast.  That thought just
 rubs me the Wrong Way, because I have a lot of respect for the time and
 trouble it must have taken these follows to get this all working in the
 first place.
 
 >When things are done, not done,
 >undone, or medium well done in FreeBSD, it tends to be by knowledgable
 >people for good reason; if things are badly considered, the developers
 >and community have never shown ANY reluctance to let it be know very very
 >very loudly.  The fact that it's been this way for this long means that
 >as a general rule, everybody agrees with it, and you'd probably get a bit
 >less heat directed at you than I've seen in just a few responses if you
 >had said 'Why is this done this why' instead of 'Why isn't this done the
 >RIGHT way, like this'.
 
 Fair enough.
 
 My only excuse is that I did (and do) in fact believe that the Right Way
 in this case is to have the save/restrore behavior.  (It seemed so useful
 to me when I first saw it several years ago that I wondered how I had gotten
 along without it for so long.)  Add to this the fact that (a) I'm a new
 convert to FreeBSD (from Linux) and that (b) since I've converted, I've
 found that NOT everything on FreeBSD is entirely sweetness and light and
 perfection.  (For example, gdb doesn't see to work on shared libraries...
 in fact it appears rather seriously broken... and the C library seems like
 it may be rather snafued also.)
 
 Please don't ask me to assume that EVERYTHING on the FreeBSD CDROM I got
 is (a) well considered and (b) the best it can be.  If we all asumed THAT
 all of the time, then there would be no forward progress!
 
 >We're all flame-happy enough already, without someone taking an agressive
 >posture over an issue that's been hashed out several times before (even
 >if they didn't know that).
 
 OK.  I apologize.
 
 I didn't know any of the history, and the whole thing did seem (and still
 does seem) just like a bug to me.
 
 (We are all creatures of habit, and I'll lay odds that there's not a one
 of us who could not be moved to emotion if the ``user interface'' which
 he/she is accustomed to using, day in and day out, were suddenly uprooted,
 tossed out, and replaced by something less comfortable and less familiar.
 That has been, in effect, exactly what I have experienced as I have moved
 my personal machine from Linux to FreeBSD recently.  Most stuff still works
 the same, but the ones that don't are really quite annoying.)
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: "Matthew D. Fuller" <fullermd@futuresouth.com>
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.)
 
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Thu Nov 18 02:33:06 PST 1999 
State-Changed-Why:  
>  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!'' 

To quote back to you your own rantings from earlier on in the same  
thread: 

>  OK.  Then you should go and make the rounds and talk with ALL of the  
>  maintainers of those programs and tell them all to add options that 
>  will allow you to _disable_ the screen save/restore capabilities 
>  which their authors labored to produce. 

Have fun petitioning the maintainers of all the packages whose behaviour 
annoys you. :-) 
>Unformatted:
