suggestion for /usr/src/UPDATING
Evan Dower
evantd at hotmail.com
Tue Aug 31 15:22:39 PDT 2004
This seems to me like a very good idea. Some people are very accustomed to
the current defaults. They can just leave things alone. I personally have to
think about which key to press, so I might change the keys to something more
suitable to me. Perhaps an /etc/mergemaster.conf is in order or any other
mechanism for allowing key (or more accurately character) customization. I
see no reason not to let everybody win. In fact, I'd be perfectly happy if
you couldn't change the default keys but could only add to them. That is, r
and l would always work, but you could configure it so that other
letters/keys would also have the same functions.
Just a thought and an opinion,
--
Evan Dower
Undergraduate, Computer Science
University of Washington
Public key: http://students.washington.edu/evantd/pgp-pub-key.txt
Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D
>From: Charles Swiger <cswiger at mac.com>
>To: Brooks Davis <brooks at one-eyed-alien.net>
>CC: freebsd-current at freebsd.org
>Subject: Re: suggestion for /usr/src/UPDATING
>Date: Tue, 31 Aug 2004 17:08:55 -0400
>
>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?
>
>_______________________________________________
>freebsd-current at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
More information about the freebsd-current
mailing list