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: [PATCH] Make `C-x {' and `C-x }' repeatable Date: Wed, 22 May 2013 14:39:14 -0700 (PDT) Message-ID: References: <87mwrombc3.fsf@mail.jurta.org> <87r4gyondh.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1369258777 7582 80.91.229.3 (22 May 2013 21:39:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 May 2013 21:39:37 +0000 (UTC) Cc: =?iso-8859-1?B?R2F1dGhpZXIg1nN0ZXJ2YWxs?= , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 22 23:39:35 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UfGkt-0005CI-Sd for ged-emacs-devel@m.gmane.org; Wed, 22 May 2013 23:39:32 +0200 Original-Received: from localhost ([::1]:56335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfGkt-0000tL-8A for ged-emacs-devel@m.gmane.org; Wed, 22 May 2013 17:39:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfGkm-0000sX-9J for emacs-devel@gnu.org; Wed, 22 May 2013 17:39:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfGkh-0002qp-Bq for emacs-devel@gnu.org; Wed, 22 May 2013 17:39:24 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:48931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfGkh-0002qh-4m for emacs-devel@gnu.org; Wed, 22 May 2013 17:39:19 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4MLdGSW001486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 May 2013 21:39:17 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MLdFmc011109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2013 21:39:16 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4MLdF97013217; Wed, 22 May 2013 21:39:15 GMT In-Reply-To: <87r4gyondh.fsf@mail.jurta.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159733 Archived-At: > I don't know why a prefix arg exits temporary-overlay-map. Trying to > (define-key window-size-adjust-keymap [?\C-u] 'universal-argument) > doesn't help to fix this. `C-u' still terminates the key sequence > `C-x } } } } C-u }'. Dunno. But anyway, as I said, the typical use case for repetition (at leas= t for me) would reuse the same prefix-arg value given to the prefix key. I= OW, I would typically not want to use a different prefix value for one occu= rrence of repetition from another. Or at least I would not want to be *obliged* to repeat the prefix arg each = time I repeated the final key. And I think that is what your approach amou= nts to (assuming you can fix it so a prefix arg does not exit the map). It would be OK for a user to be *able* to employ a new prefix arg along the= way, for a one-off final-key occurrence. But you wouldn't want to be forc= ed to keep providing a prefix arg for each final-key repetition.=20 > > I want to have a repeatable command bound to a key on `isearch-mode-map= '. >=20 > In bug#10654 I proposed a patch that implements repeatable keys for Isear= ch > e.g. `M-s C-f C-f M-f C-f ...' Yes, I saw that. Good. I would still prefer a simpler approach. You are = essentially requiring each repeatable command to set variables `isearch-rep= eat-command' and `isearch-repeat-key'. (That might be similar to the older= approach used in repeat.el - dunno.) I would prefer something simpler, using either an approach like `set-tempor= ary-overlay-map' (which you proposed for this thread) or an approach like `= repeat-command' (which I mentioned). Both of those allow for short, simple= & clear command definitions. The former has the advantage that you can define the map to include a set o= f keys, any of which can be the repeatable final key (mix & match within th= e set). Of course it means creating a different map for each such set of keys. E.g= ., if you want several such sets on the same key prefix, but you want them = to be separate - so that, e.g., you could repeat with `C-x a b c a b b' or = with `C-x m m o n o o', but not with `C-x a b m a n'. And you would need to use a singleton map if you wanted a singleton final-k= ey set. E.g, if you want to get the effect that repeat.el provides of allo= wing `C-x a a a a' and `C-x b b b', but not C-x a b b a, then you would nee= d two singleton keymaps. IOW, it is good to be able to define sets of final keys that work together,= repeating any of them without needing to repeat the prefix key. Code that= lets you do that simply, even for the singleton set case, and preferably w= ithout needing to define multiple global vars, would be preferable. FWIW, I have all of these "yank" keys on prefix `C-y' in Isearch: `C-y C-(' `isearchp-yank-sexp-symbol-or-char' `C-y C-2' `isearch-yank-secondary' `C-y C-c' `isearchp-yank-char' `C-y C-e' `isearchp-yank-line' `C-y C-w' `isearchp-yank-word-or-char' `C-y C-y' `isearch-yank-kill' `C-y M-y' `isearch-yank-pop' 5 of those commands are repeatable. But because I use `repeat-command' to = implement this, you cannot mix and match these within the same `C-y' occurr= ence: each is separately repeatable (e.g., `C-y C-e C-e... C-y C-w C-w' is = OK, but not `C-y C-e C-e C-w C-w'). (And anyway, the repeatable Isearch commands have stopped working because o= f bug #14095.) > Maybe a better implementation would be with the help of > `set-temporary-overlay-map'. Only, I think, if bug #14095 gets fixed. I think it's the same problem. The problem that bug #14095 points out is that `set-temporary-overlay-map' = does not work with Isearch because its map does not override the map used b= y Isearch. `overriding(-terminal)-local-map' (used by Isearch) overrules t= he temporary map used by `set-temporary-overlay-map'. > I'll try to do this for Isearch. See previous. AFAICT, it won't work to use `set-temporary-overlay-map' the= re, unless bug #14095 is fixed. > But it seems repeat.el can't be used if there are different commands > in the key sequence. No (i.e., correct), at least not the way I did it. I thought for a moment that perhaps one could somehow leverage a sequence v= alue of `repeat-on-final-keystroke', to allow such behavior, but I guess no= t. Too bad. I guess that's only for allowing multiple "alias" keys for th= e *same* repeatable command (not for multiple commands intended to be used = together). (And I'm not even sure how you would use that option for keys such as . Any idea? I tried fiddling with option values but couldn't make it wo= rk. And why the doc speaks of "characters" instead of keys, I don't know.)