>>>>> Drew Adams writes: > I started to reply in a similar vein to Eli. On rereading John's mail I saw > that he tried to separate what the behavior is for users from how the > behavior is implemented, and his argument seems to be only about the latter > (although it was not made as clearly as it might have been, IMO). > IOW, I don't think John is arguing against the UI design of letting a key > such as `C' or `F' in Dired have different behaviors depending on the use of > a prefix arg. > I think his only argument is about how that (good, not bad) behavior is > implemented. He argues that there should be a separate function for acting > on only the current line's file and not the marked files. Hi Drew, you've summed up very well the point I was trying to convey. My apologies if any hand-waving was perceived; I'd be happy to construct code examples on any point, if that is needed. The reason for my comment is that the original patch requested adding a new argument to an existing function, in order to special-case the behavior of that function in a way that does not fit with its current name and purpose. I'd rather have two functions and a new command that calls the appropriate function based on its context of use. What I to avoid is coding special behavior into existing functions -- *in the implementation* -- simply because it is convenient. It still bothers me that `call-process-region' does this, for example, with its many and varied meanings of the "START" argument -- some of which relate neither to the meaning of "start", nor of "region". When it comes to UI, I'm in complete agreement with Eli: I love DWIM behavior, and think this is a virtue of Emacs, not a vice in any way. So yes, I'm just thinking about the code: modularity, ease of maintenance, clarity of purpose. These may be not be terribly specific statements, but they are the motive for my comments. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2