Bug 14959

<<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

[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"

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.

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"

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''.)

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"

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.)

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.)

Comment 9 Sheldon Hearn 1999-11-18 10:33:06 UTC

State Changed
From-To: open->closed

>  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. :-)