>>>>> Eli Zaretskii writes: >> 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. > If DWIM is okay in the UI, then functions that behave in support of that UI > should also be okay. Since this responses surprised me a bit, I'm going to assume that I've misunderstood somehow. Let me give a hypothetical example: Assume for the sake of argument that `count-lines' did not report characters as well, and that someone wished to extend the `count-lines' command so that, given a prefix arg, it would count characters instead of lines. What I think should happen in this case is that a new command be created: count-items-in-region, which by default counts lines, but with a prefix argument counts characters. This leaves that command open to many new behaviors in future, while `count-lines' keeps doing just what it says: count lines. What I would object to is adding a new argument to `count-lines', called `characters-p', that changes the behavior of count-lines to now count characters instead (again, remember this is hypothetical, I know that today's `count-lines' already counts characters as well). Just because I want DWIM from my interface, doesn't mean I need to implement it as DWIM in my functions. I believe -- very strongly -- that each function should do one thing and one thing well, and this one thing should be documented well. I don't like magical functions with lots of alternative behaviors, unless it is a command created for the purpose of magically dispatching to other functions based on its context of use. Such magical interface functions are quite alright in my book; but complexifying the behavior of core functions is not. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2