Date: Wed, 17 Nov 1999 14:50:02 -0800 (PST) From: "Ronald F. Guilmette" <rfg@monkeys.com> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) Message-ID: <199911172250.OAA42315@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: "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.) 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?199911172250.OAA42315>