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

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

> > > If you compare the first patch with `dired-get-marked-files' (d-g-m-f)
> > > you might change your mind: (d-g-m-f) returns a list with the file at
> > > point when there are no marked files. The first patch follow similar 
> > > idea.
> >
> > I understand dired may also be taking this bad approach, but that's not
> > a good reason to continue the practice.
> 
> But it isn't just Dired.  Having the marked items default to the
> current one is a very frequent idiom in Emacs modes that present lists
> of actionable items.  It is also consistent with what GUI file
> managers out there do.
> 
> > Functions should do what they say, and not have lots of alternative
> > functionality baked into them because it's a convenient hack today.
> 
> There's a clash here between this goal, and the goal of being
> DWIMish.

1. Distinguish (a) behavior for users from (b) its implementation.

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.

And as I mentioned, it is often the case that there _is_
such a separate function.  And it is often a command.  But
it is typically not bound to a key - it is used only for
a menu-item binding, since the general `C', `F', etc. key
does double-duty.

There is generally no need to bind a key sequence to such
a this-file command.  Put differently, there already _is_
a key sequence that gives you that behavior: a prefix arg
(`M-1') followed by the multiple-files key: act on only
one file - this one.

So I think this is some (not much) ado about nothing.
The UI is a sound and useful one.  And the implementation
is also not bad - it generally does not conflict with
John's request for single-purpose functions.  Specific
single-file functions are not always needed in Dired,
but when they are needed (e.g., for a menu item), they
exist.

And a utility function that accepts args that control
variant behaviors is also not necessarily a bad thing,
IMO.

No one would argue that `mapc' is bad because it is
parameterized by a function argument that determines
the outcome/behavior.  No one would outlaw it because
it violates a single-function-per-behavior principle.
Likewise, no one would propose removing `if' because
it allows for different behaviors.

The devil is in the details.  That's my critique of
John's comments - too general/vague.  To discuss
whether there is really a problem in this case, the
complaint should be specific, about the actual code,
not just couched in general software-engineering terms.

The talk of "bad approach" and "monkey-patching" was
misplaced, I think.  There is a sermon there, but I
don't think there is a sinner to be preached to -
only fellow choir members. I think that John spoke
in too-general terms, with some hand-waving.

Even if we single-purpose functions, so they satisfy
John's "principled way", there can be an advantage,
for interactive use, in combining them in _commands_
that can have multiple, alternative behaviors.  I
think John acknowledges this and even said much the
same thing.

And providing different behaviors in the same command
is not just a holdover from "prior art".  It is an
important possibility/feature that the basic design of
Emacs offers (and yes, that it has used in commands
provided by default, from Day One).

That does not mean that just any old throwing together
of behaviors in a single command is a great idea.  It
means that some commands that provide for multiple
behaviors can be good things, not bad.

IOW, one size/principle does not fit all use cases.
What justifies something like the prefix-arg behavior
of Dired commands for marked files is not the fact
that it is "prior art".  No one argued that.  That
neither justifies nor invalidates it.  What justifies
it is the judgment that the behavior is helpful for users.

That's where the argument about what behavior to
provide needs to take place: in the realm of behavior
for users.  Not just in the realm of code organization
for easy and sound maintenance.

There are cleaner & dirtier ways, and easier & harder
to maintain ways, to implement a given behavior.  The
question about the _usefulness for users_ of such Dired
(or Ibuffer) commands is the question to address first.
Questions of implementation choice should follow that
question, not vice versa.

I think (and hope) that John does not feel very different
about this.


2. As for DWIM, which Eli mentions: This is not about DWIM.

I distinguish (a) the ability for users to obtain
different, alternative behaviors from a given command
from (b) DWIM commands.

The former gives the user full control.

A DWIM command is some programmer's idea of what would
be the right behavior within a given context.  It is
the command (code), not the user, that is in control.
The behavior choice is essentially made at coding time.
It is not made by the user, at runtime.

That does not mean that DWIM is always stupid, bad, or
misguided.  It means only that it is something different
from a user choosing to provide a given prefix arg, to
get a particular member of a command's set of behaviors.

In general, I'm strongly in favor of commands providing
multiple behaviors, which a user can choose from.  What
is important is that (a) the behaviors somehow belong
together in the same command, (b) the default behavior
is the common one, and (c) the doc makes clear what the
behaviors are and how to obtain them.

To me, Dired's `dired-do-*' commands (`C', `F', etc.)
are well designed.  The alternative behaviors collected
in the same command belong together; the commonly used
behavior is the default; and the doc about them is clear
enough.