From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:09:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB30A16A4CF for ; Tue, 31 Aug 2004 21:09:17 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 753E743D1F for ; Tue, 31 Aug 2004 21:09:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7VL9HkN009051; Tue, 31 Aug 2004 14:09:17 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VL8uCv022754; Tue, 31 Aug 2004 14:09:01 -0700 (PDT) In-Reply-To: <20040831203131.GA25134@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 31 Aug 2004 17:08:55 -0400 To: Brooks Davis X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 21:09:17 -0000 On Aug 31, 2004, at 4:31 PM, Brooks Davis wrote: >> I am content to let any interested committer make that decision, but I >> ask that whoever first go through a trial mergemaster session using >> '1' & '2' as the keys. 'q' and 'e' are right there, and I found the >> improvement compared to using 'l' & 'r' immediately obvious and more >> intuitive. > > I agree the current default is confusing and counterintuitive, at least > at first. That's not the point. The point is that it's been that way > for ages and changing it would gratuitously screw all the users who > have > adapted to it. There's no reason why you couldn't preserve the old > behavior by default and in fact I'd request a back out of any commit > that didn't. I don't opposes adding a second set of keys such as 1 and > 2, just breaking the old behavior. I am more interested in permitting users to choose which keys they prefer to use than I am in arguing what should be the default behavior of sdiff. It seems likely that if I'd commented out line 10 of my diff rather than line 9, I'd be dodging brickbats from the other side, but what the hell, the diff is the way it is because I wanted to test and see whether the changes actually made a noticable difference in usability. I came to a conclusion, but the code I submitted is more friendly about supporting individual opinions than the prior code, and your suggestion to support multiple keys for choosing left and right also sounds like a good idea-- probably more doable if one started with my changes. -- -Chuck PS: I was going to ask, Brooks, whether you could describe a process you'd tolerate for changing the default behavior of a program with unreasonable defaults?