emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ibuffer: w and B default to buffer at current line


From: John Wiegley
Subject: Re: Ibuffer: w and B default to buffer at current line
Date: Sat, 17 Sep 2016 14:35:57 -0700
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (darwin)

>>>>> Eli Zaretskii <address@hidden> 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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]