Date: Wed, 17 Nov 1999 14:00:02 -0800 (PST) From: "Matthew D. Fuller" <fullermd@futuresouth.com> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) Message-ID: <199911172200.OAA32808@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/14959; it has been noted by GNATS. 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" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911172200.OAA32808>