From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: keyboard-escape-quit (was: delete-selection-mode) Date: Sun, 21 Mar 2010 00:09:35 -0700 Message-ID: <190DD0E028DD406C92A347871C657BDE@us.oracle.com> References: <4BA0CDF9.40707@online.de><76682E4761EA432EB929E5E199B0F92A@us.oracle.com><87wrxb57e1.fsf@lola.goethe.zz><20100317.200901.408057447.hanche@math.ntnu.no><87sk7y2gh9.fsf@lola.goethe.zz><69FB036BE1D649E0B76B257ED3D3F6EA@us.oracle.com><87vdcs13fp.fsf@mail.jurta.org><33B1AA2E77404CC694AEB05CA1D667FE@us.oracle.com> <87aau2mw0a.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269155526 17929 80.91.229.12 (21 Mar 2010 07:12:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 21 Mar 2010 07:12:06 +0000 (UTC) Cc: 'Stefan Monnier' , emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 21 08:11:57 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NtFKG-0005mw-KI for ged-emacs-devel@m.gmane.org; Sun, 21 Mar 2010 08:11:57 +0100 Original-Received: from localhost ([127.0.0.1]:42577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtFKF-0004TJ-5r for ged-emacs-devel@m.gmane.org; Sun, 21 Mar 2010 03:11:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtFJi-0004SP-MK for emacs-devel@gnu.org; Sun, 21 Mar 2010 03:11:23 -0400 Original-Received: from [140.186.70.92] (port=41368 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtFJ6-0004OB-V0 for emacs-devel@gnu.org; Sun, 21 Mar 2010 03:11:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NtFIO-0003Wg-Lz for emacs-devel@gnu.org; Sun, 21 Mar 2010 03:10:44 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:58121) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NtFIN-0003WL-P8 for emacs-devel@gnu.org; Sun, 21 Mar 2010 03:10:00 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2L79vCP031029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 21 Mar 2010 07:09:58 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2L68RqG003739; Sun, 21 Mar 2010 07:09:56 GMT Original-Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 103071351269155372; Sun, 21 Mar 2010 00:09:32 -0700 Original-Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Mar 2010 00:09:31 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrIjxh5etM69zzOS8q0QbJdQKwfEgADeCDA In-Reply-To: <87aau2mw0a.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BA5C645.0033:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122403 Archived-At: > > 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.