RE: keyboard-escape-quit (was: delete-selection-mode)

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

> > Interesting, but I think we need a key that doesn't have 
> > any meaning in the context where a region might be active.
> > Maybe that means we need a key that isn't yet bound; dunno.
> 
> I use `keyboard-escape-quit' all the time to deactivate the region
> without any problem.

FWIW - I never paid any attention to `keyboard-escape-quit', for some reason.
Taking a look now, I am perplexed.

The description of `keyboard-escape-quit' indicates that it means everything and
nothing, does everything and nothing:

  Exit the current "mode" (in a generalized sense of the word).

It apparently cannot even be described clearly. The description refers to a
fuzzy concept of `mode' with no explanation, and it even puts `mode' in quotes,
to make it even fuzzier. Then it adds a parenthetical expression that
generalizes it still more. Hard to get any fuzzier.

As Coluche said, when one can't say anything clearer than that, one might as
well say nothing at all. ;-) The only real take-away from the explanation is
that the command in some sense _exits_ from something or other. What "exiting"
means is left open. What is "exited" from is left open. Deliberately,
presumably. I suppose that's the whole point, but it doesn't help me.

So the rest of the doc string is then a laundry list of examples of different
kinds of "exiting" from different kinds of "modes", presumably to give some
flavor of what the command could be used for:

   This command can exit an interactive command such as
   `query-replace', can clear out a prefix argument or a
   region, can get out of the minibuffer or other recursive
   edit, cancel the use of the current buffer (for
   special-purpose buffers), or go back to just one window
   (by deleting all but the selected window).

That just shows that the meaning is even more nebulous than the first line alone
indicates. And this sorry situation is apparently not new - the Emacs 20 doc
string is the same.

What's also interesting is that this function is apparently not used anywhere in
the Emacs source code, apart from binding it globally to ESC ESC ESC. If used
interactively, it does call `deactivate-mark' to deactivate the region - OK,
that much is clear.

The doc string of `keyboard-escape-quit' also gives the example of exiting
`query-replace', but `ESC ESC ESC' does not do that for me. Instead, a single
ESC seems to exit completely.

`keyboard-escape-quit' would just return nil if it were invoked during
`query-replace' (e.g. by ESC ESC ESC). That would happen because the
`query-replace' code sets `this-command' to `mode-exited' when it encounters an
unrecognized character. And the `query-replace' (`perform-replace') code that
does that has essentially exited at that point, AFAICT. So if it were invoked,
`keyboard-escape-quit' would effectively exit, AFAICT.

However, I don't see how `keyboard-escape-quit' could actually be invoked during
`query-replace', since ESC (not ESC ESC ESC) is bound in `query-replace-map' to
the pseudo-command `exit-prefix', which the code immediately treats as an
unrecognized character (setting `this-command' to `mode-exited').

The impression I get is that `query-replace' essentially just exits when
`perform-replace' handles any unrecognized char (such as a single ESC), and that
the code never goes through `keyboard-escape-quit'. But I admit that what really
happens isn't clear to me. 

`perform-replace' does put the unrecognized char/key onto
`unread-command-events', so maybe there is something special going on wrt an ESC
char in `unread-command-events' and the key sequence ESC ESC ESC (?). But a
single ESC does exit, for me.

Another thing that's unclear to me are the statements in the doc to the effect
that ESC ESC ESC "cancels a prefix arg" or "clears out a prefix arg". Howzat?
What's that about? Can someone give a recipe/example for this?

---

Anyway, I'm not sure what your point about region deactivation is, Juri, but it
seems to me that we would be better off making the key and command that
deactivates the region more specific, not less. To me, it makes sense to have a
dedicated command (and maybe a key) - one that does only that.

Yes, I realize that `keyboard-escape-quit' does the job, it exists, and it is
documented. Still, it seems like a weird mix.

> I think in `keyboard-escape-quit' deselecting the region
> should have a higher priority than deactivating the
> minibuffer because it's possible to select the region in
> the minibuffer, and when the minibuffer is gone
> then there is no region to deselect anymore.  IOW, the 
> current behavior breaks the logic of `keyboard-escape-quit'
> that should cancel one active feature per invocation.

Yes, well it all depends on what behavior one (some code) might want, doesn't
it?

If we try to reuse that key, then we have to define a sequence of priorities, as
you describe. Things become less flexible. What seems odd to me is that we even
defined such a hybrid as `keyboard-escape-quit'.

It seems right to me that we have some key that does only the one thing:
deactivate the region. Whether we then might also want to sometimes combine
deactivation with other actions and bind such a combination to some other key is
another matter.

I can't speak to your point about reordering current priorities for
`keyboard-escape-quit'. I'm not very familiar with it and I haven't thought
about this.

My only point is that if we don't like C-g for region deactivation (and that was
the starting point), it's precisely because C-g means and does other things as
well. And the same is apparently true for ESC ESC ESC: it's a mixed bag.

I think we should pick some unused key for (just) deactivating the region. But
I'm pretty ignorant on this subject - I might well be wrong. I'm going by
intuition more than understanding, here.