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: have cake will eat, eatcake will have - krazy key koncept kontroversy Date: Fri, 28 Aug 2009 08:34:28 -0700 Message-ID: References: <732931969EE046E8A44CE77C4FD88C64@us.oracle.com> <5f0660120908272335u64242281o1e2716c662dd8ca5@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1251475956 30412 80.91.229.12 (28 Aug 2009 16:12:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2009 16:12:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'?????? ?????????'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 28 18:12:29 2009 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.50) id 1Mh43v-0007hW-RW for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 18:12:28 +0200 Original-Received: from localhost ([127.0.0.1]:44619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh43v-0003Nj-1o for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 12:12:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mh3wV-0003Dp-92 for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:04:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mh3wP-00037h-A8 for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:04:45 -0400 Original-Received: from [199.232.76.173] (port=36035 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh3wP-00037Z-3j for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:04:41 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:32161 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mh3wO-0005Ld-CM for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:04:40 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7SG50CN009727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2009 16:05:02 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7SG4TGM011477; Fri, 28 Aug 2009 16:04:30 GMT Original-Received: from dradamslap1 (/24.5.190.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Aug 2009 08:34:29 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5f0660120908272335u64242281o1e2716c662dd8ca5@mail.gmail.com> Thread-Index: AconqfEDCY6jY5t9TuaCrBrtgBY9ngAQoKtw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4A98000E.0189:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:114770 Archived-At: > > Using the technique I mentioned, you can get the behavior=20 > > you listed (C-x o, C-x o o o..., C-x C-x, etc) immediately: > > > > (defun other-window-repeat () > > =A0(interactive) > > =A0(repeat-command 'other-window)) > > > > (define-key ctl-x-map "o" 'other-window-repeat) >=20 > Is it possible to make *all* key sequences repeatable? Creating the > above code for every single key sequence is tiresome... I don't think we would want to. One of the points I tried to make was that all of these considerations = depend on the particular keys, commands, context, etc. Currently, we do waste some repeatable keys on non-repeatable commands = (e.g. C-M-x for something you won't want to repeat). Sometimes (e.g. C-M-x) = this can still be a good idea. It's not because we _could_ do this to all keys = that we would want to. Simlarly, it's not because we _could_ make all prefix keys also perform repeatable actions that we would want to. The point is (a) to think about conserving such = easy-to-repeat-by-pressing keys and chords, and (b) that one way to conserve them can be to give = repeatable actions to prefix keys (in addition to their role as prefix) - and to = give a prefix role to keys that are currently used only for actions.=20 > > The real point was to be able to use this technique also=20 > > for a prefix key: to be able to have a prefix key perform > > some action when repeated. Why? > > > > a. To have additional easily repeatable keys (giving=20 > > existing prefix keys double duty). > > > > b. To have additional prefix keys (giving existing=20 > > non-prefix keys double duty). >=20 > My proposal solves a) and b) too: >=20 > a) C-x C-x becomes easily repeatable (1 + n instead of 2n keys for n > repeatitions); >=20 > b) You may make C-a prefix key, and bind C-a C-a to repeatable command > (again, 1 + n keys for n repeatitions, like in your method). If, by your proposal, you mean what you sent before, then no. As I = explained, if you expect a prefix key to act in some way (e.g. as `forward-char') the = first time it is pressed, then it cannot also be a prefix key. Well, it could be done, but with some jimmying. We could use a delay, as = Juri pointed out CUA-mode does. Or we could try to undo the action (from the = first C-a) if the following key is a legitimate suffix for that prefix, and = then do what the suffix says. We could perhaps come up with other such workarounds. But the problem to = be worked around (or not, as in my suggestion) is that when a prefix key is = pressed once, you cannot know what is to follow - in general you must wait and = see, before doing anything. > Is it correct that the difference between our proposals is=20 > the following? >=20 > 1) Your method requires user to bind the prefix key (e.g. C-x, M-s h). Users can do it themselves, of course. But my suggestion was for Emacs = to do it, for some set of keys that Emacs developers would agree on. We would bind the prefix key as its own suffix, yes.=20 But not the whole prefix key - just its smallest nonempty tail. (If the = only nonempty tail is the whole key, then yes, the whole key.) In the case of = prefix key `M-s h', it is the tail `h' that we would bind to a repeatable = action, not the whole prefix key `M-s h'. We would bind `h' as a suffix in the = prefix-key's map, that is, the map for `M-s h'. To make `C-x' after `C-x' and `h' after `M-s' repeatable, we would bind = `C-x' and `h' to `-repeat' commands. In the former case, the = binding would be in the ctl-x-map; in the latter case, it would be in the `M-s h' map. `M-s h h' is then defined as a repeatable action, so `M-s h h h h...' = works, the first action occurring with the second `h'. > 2) My method requires user to bind the whole key sequence for the > first repeatition (e.g. C-x C-x, M-s h h). Sorry, I don't follow you. Please show some code or an algorithm. Or = walk through the binding steps you have in mind.