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

[Drew Adams <drew.adams@oracle.com>]

> 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).

Seems like you're confusing a few things.

Is your point about the evolution of an existing function?  You
don't want to affect the longtime behavior of an existing function?

Or is it about having a single function (`count-items-in-region'),
from the outset, that can count different things depending on the 
presence/value of an optional argument CHARACTERS-P or ITEM-TYPE?

Is it the multiple behaviors that bother you, or the fact that
some existing function is being changed/affected?

> I believe -- very strongly -- that each function should do
> one thing and one thing well,

Define "one thing".  Does `mapc' do one thing: map a function
over a list; or does it do any number of things, depending on
its function argument (and its list argument, for that matter).

Is your argument limited to behavior from &optional arguments,
or does it apply also to required args too (e.g. the FUNCTION
arg of `mapc').  Does it make a difference in your understanding
of "do one thing" whether `count-items-in-region' takes a
required CHARACTERS-P or ITEM-TYPE arg or that arg is optional?

> and this one thing should be documented well. I don't like
> magical functions with lots of alternative behaviors,

What constitutes "magical", for you?  How many alternative
behaviors is "lots", for you?

Yes, it would annoy me too if I had to try to answer such
questions. ;-)  But that's the cost of such generalizing, I
think.  Better to discuss such things in specific, concrete
cases.  That keeps arguments a bit more grounded.