bug#3746: M-r in comint mode should use isearch

[Drew Adams]

> So when point is on the shell prompt then run Isearch on
> the shell history, otherwise run Isearch on the shell buffer.

Why?

I don't really want to get involved in this thread. I will say though that the
approach just quoted is a good example of the weakness  of DWIM.

A better approach, generally, is to give users explicit control, without such a
dependence on fine-grained context or mode. IOW, in this case, have the two
different kinds of search be initiated by a user differently, using two
different commands/keys. That's the typical, simple, straightforward Emacs
approach.

The DWIM approach, far from always making things easier for users, complicates
the mental models they need to use to make sense of their interactions with the
program. They need to be aware (not necessarily consciously) of much more
contextual state. The behavior is more complex, not less.

That's not to say that users can't make use of it or that they need to be
consciously thinking about complex contextual issues all the time. Like riding a
bike or driving a car, this can soon become unconscious and natural (provided
they use it a lot).

The general objection is rather Occam's razor: _Why_ add such complexity? What
is gained? Occasionally the added convenience of having a single key to use
makes a DWIM command worth it. But usually not.

If the two behaviors and their triggering contexts are complementary and quite
separate, then it can sometimes be worth it. But just combining behaviors on the
same key binding whenever there is some degree of context difference is not
justified, on its own. Just because Isearch on the history and Isearch on the
buffer have no target overlap is not in itself a sufficient reason to combine
them on the same key.

Put another way, is it really worth it in this case to make the command behavior
more complex, just to avoid having two key bindings? What reasons can you give?

One can look throughout Emacs and find plenty of commands/keys that _could_ be
combined, pushing the decision of which command to apply from the user into the
combo-command, according to context. But very few commands merit such
combination. 

I'm sure you could combine some commands/keys in almost any major mode - from
Dired to *Buffer List* to view-mode to almost anything. There are commands that
make sense only in certain contexts and so could be combined. But _why_ do that?
You could make `U' in Dired do something different when no files are marked. You
could perhaps combine that with `#' to do something when there are no auto-save
files. But why?

You get the idea: Combining different commands on the same key, to take
advantage of their applicability in different contexts, makes the UI more
complex; it forces users to consider the context. All that's gained is a
keystroke or two. Generally, it's not worth it.

Some argue that having lots of commands and lots of key bindings is also
complex. Yes, but then the different features are more separate, explicit,
independent. They are not linked by state/mode changes. States and modes are
among the most complex UI critters for users to tame, and they are largely
invisible/virtual.

Each time there is a DWIM proposal like this, I'd like to see a little extra
justification - justification for the combination itself: why one complex
command instead of two simple commands? If this isn't supported by argument each
time, we might well find ourselves soon in a maze of DWIM, with people emulating
such tricky combination more and more.

Programmers like to be clever, and DWIM is a cute cleverness trap. Like trying
to eke out extra functionality from fewer bytes of assembler code, apparent
cleverness can have a price in ease of change, ease of use, and ease of
understanding.