RE: on adding a function call to a s-exp

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

> > DWIM guessing
> 
> DWIM is far from the computer "guessing" what the user wants!

Yes, that should be obvious.  It's a loose use of the
term "guess".  (It's more that users can have to guess
what's going on.)

> Because the different actions are very
> predictable based on the current state (which
> is known, all clear and visible, and often part
> of the workflow just one second ago), the Emacs
> user is very aware of what is going on, and the
> computer response is equally predictable!

Predictable in the code does not imply visible to
users and understood by them.

It doesn't follow that just because (1) the code of a
command is deterministic and can be well understood,
(2) a user understands it or knows what to expect.

The real problem comes when Emacs (e.g. by default)
substitutes a complex DWIM command for a clear command
with a simple behavior, e.g., by changing the default
key binding or by just redefining the command.

But just think about the name "DWIM".  It supposes
(claims) that the predictable behavior of the code
is just what you, a user, really want to happen in
your current context.  Really?  In that case, all
DWIM commands can be equally applied in any context,
and they all do what you want. ;-)

What it really comes down to, I think, is that some
programmer wrote a command that s?he thinks is handy
in some context, and s?he wants to get the point
across to users that it does different things, depending,
and that users will be happy with what it does, without
knowing just what or why.

The code assumes that if this, this, and that condition
hold then what the user wants is this behavior.  Yes, in
effect it's guessing what the user wants in that context.
The programmer guessed.  The user might be guessing too
(What's going on?).  But the code is deterministic.  

----

To be clear, I do define and use some commands that
one might call "DWIM".

But the possible alternative behaviors typically depend
on an explicit user choice, e.g., by using different
kinds of prefix arg.  Multiple behaviors are still
available on a single key, but they're picked by
explicit user action, not by context.

A _command_ picking a behavior based only on context
requires a user to understand what the context is, as
defined by that command.  Sometimes that's fine.
Sometimes it's not clear at all.

A _user_ picking a behavior pretty much guarantees that
s?he agrees with that choice (modulo misunderstanding).

Sure, in both cases a user might need to consult the
doc string of the command.  But in the case of explicit
user action the user at least (usually) knows what s?he
did and can figure out what the resulting behavior is
all about.

As an example of a quite complex command that I defined
and use, consider `secondary-yank|select|move|swap'.

Yes, someone else might have called it `secondary-dwim'
(and that's what I called it at first).  I prefer the name
I use now.  Anyway, you use it via a key (I use `C-M-y').

What does it do?  `C-h f' tells you:

__________________

 secondary-yank|select|move|swap is an interactive compiled Lisp
 function in ‘second-sel.el’.

 It is bound to C-M-y, menu-bar edit secondary-yank|select|move|swap.

 (secondary-yank|select|move|swap ARG)

 Yank the secondary selection.  With a prefix arg, interact with region.
 Prefix arg:

  None: Yank secondary.
  Zero: Select secondary as region.
  > 0:  Move secondary to region.
  < 0:  Swap region and secondary.

 Details:

 No prefix arg: Yank the secondary selection at point.  Move point to
 the end of the inserted text.  Leave mark where it was.

 Zero arg: Select the secondary selection and pop to its buffer.

 Non-zero arg: Move the secondary selection to this buffer’s region.

 Negative arg: Also go to where the secondary selection was and select
 it as the region.  That is, swap the region and the secondary
 selection.
__________________

So the default behavior is just to yank the secondary
selection.  In any context.  Doesn't matter whether the
moon is full or the coast is clear.  Same with each of
the alternative behaviors (which are used much less).

And each of those possible actions is also realized by a
separate command, so you are not _obliged_ to bind and
use only the complex command.

And the doc tells you what it does, and its name suggests
the combination that it is.

The name `secondary-dwim' tells you nothing, except that
there's some mystery to check out.

And not all DWIM commands have doc that accurately and
clearly describes context-dependent behavior.  Too often
they count on the behavior being "what someone would want",
and related to that assumption is the assumption that no
one needs to be told what they do.  Just try it - it'll do
what you want/expect.  No, not always; not so much.