From owner-freebsd-bugs Fri Nov 19 9:48:50 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 20000156E4 for ; Fri, 19 Nov 1999 09:48:46 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id JAA95696 for ; Fri, 19 Nov 1999 09:48:44 -0800 (PST) To: freebsd-bugs@FreeBSD.org Subject: Re: misc/14959: incomplete xterm termcap entry (see also bug gnu/5039) In-reply-to: Your message of Fri, 19 Nov 1999 08:20:25 -0500. <19991119082025.A12676@mad> Date: Fri, 19 Nov 1999 09:48:44 -0800 Message-ID: <95694.943033724@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19991119082025.A12676@mad>, Tim Vanderhoek wrote: >On Thu, Nov 18, 1999 at 08:44:36PM +0200, Sheldon Hearn wrote: >> >> > One of them is `more'. >... >A couple notes: > >1) The -e option is destined to become sub-useful (though perhaps not > to die...). The -e will turn on by default when one of tags, > bookmarks, multiple files, or files with #lines > screen_length > is true. See Joerg's comment, circa the middle ages, in the cvs > history. > >2) It's not clear from the conclusion of this thread (was there a > conclusion?) that hacking individual programs is the best thing to > do. It seems to me that it may, however, be the best thing to > do... My own personal ``final conclusion'' is that I should probably just do what someone (I forget who) early on in this thread kinda hinted that I should do... i.e. just go away. I think that the post by Gregory Bond made it clear that regardless of my personal beliefs about how this should all be done ``right'', I'm swimming against the tide of history with regard to _both_ the notion of adding options to various programs to allow their users to disable screen save/restore selectively _and_ also withj regards to the notion of maybe enhancing termcap so that it would have separate and distinct codes for the terminal save & restore operations. Gregory Bond's point that termcap/terminfo is _all_ just one big mechanism for dealing with thing (i.e. ``terminals'' of more or less ``intelligence'') that are now basically an obsolete technology is well taken. I have to admit that there really are only three types of ``terminals'' that I have had any reason to care about with at least the past 5 years, i.e. xterm, an x86 console, and a Sparc console. So yet, given the hassle factor involved with getting _anything_ changed with respect termcap/terminfo, and given that termcap/terminfo is largely going the way of the dinosaur anyway, I for one am not inclined to worry too much about this issue anymore _or_ to attempt to get the evident problems with both termcap and the programs that use it ``fixed'' in a proper way. I have a hack/kludge/whatever that seems to work for me at the moment, and guess I'll let it go at that. (Obviously, somebody up there is trying to tell me that its past time for me, as a person, to give up on my oldtime hacker command line orientation, time for me to just join the point-and-drool crowd, and time for me to just stop using xterm. History has spoken, and now it is _me_ that's rapidly becoming the dinosaur. And no, I'm not kidding. I'm just about to switch from using MH to using Netscape Messenger for my mail reading & writing anyway. I have seen the future, and it is gooey... er... GUI.) P.S. I think that maybe I just now discerned yet another way to get the general kind of behavior I want from vi anyway... I guess what I really want is just a `xvi' command which, when invoked, will just pop up a whole new/separate xterm window... leaving the current one unscathed... and which will just run vi in that new xterm window. Yea. That would work too, and I can brpbably just make that a C-shell alias. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message