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: Thu, 23 May 2013 09:19:33 -0700 (PDT) Message-ID: <8963bd95-a5fc-4f2a-b8fc-40dbc7074809@default> References: <87mwrombc3.fsf@mail.jurta.org> <87r4gyondh.fsf@mail.jurta.org> <6CA0C904-94F7-4ECF-A8E0-BC78844E5348@mit.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1369325999 6322 80.91.229.3 (23 May 2013 16:19:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 May 2013 16:19:59 +0000 (UTC) To: chad , "emacs-devel@gnu.org Development" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 23 18:19:58 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 1UfYFA-00028M-9i for ged-emacs-devel@m.gmane.org; Thu, 23 May 2013 18:19:56 +0200 Original-Received: from localhost ([::1]:51534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfYF9-0003l8-Qw for ged-emacs-devel@m.gmane.org; Thu, 23 May 2013 12:19:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfYEz-0003by-5g for emacs-devel@gnu.org; Thu, 23 May 2013 12:19:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfYEr-0005Zt-Tc for emacs-devel@gnu.org; Thu, 23 May 2013 12:19:45 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:23323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfYEr-0005Zk-Me for emacs-devel@gnu.org; Thu, 23 May 2013 12:19:37 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4NGJXFh030245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 16:19:34 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4NGJYOB008471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 May 2013 16:19:35 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4NGJY6T021145; Thu, 23 May 2013 16:19:34 GMT In-Reply-To: <6CA0C904-94F7-4ECF-A8E0-BC78844E5348@mit.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:159748 Archived-At: > > There is also the question (assuming a fix that would apply the prefix > > arg from the prefix key to each repeated final key) of whether using a > > prefix arg before an individual final key should affect only that key > > occurrence or all subsequent key hits as well. >=20 > I haven't tried this yet, but I imagine that I would want subsequent > commands to *ignore* the prefix. For example, I would grow a window > by 4 or 16, then use single keystrokes to fit more accurately from > there. I do something similar to this now with a simple macro > (long-since built into my fingers) that grows a window by 12. Good point. That is indeed another use case. > Have you perhaps tried this behavior with window-sizing commands? > Did it feel more natural to always adjust the window by a large > increment, or did you find that you typically adjusted it by a small > increment and repeated the growth multiple times? I would probably prefer that the prefix arg be applied modally here. IOW, the last prefix arg be used for subsequent repetitions until I change = it. That way, when and whether to change to a more or less fine-grained increme= nt is up to me, not to some hard-coded rule. E.g., what you suggest is to always immediately revert to no prefix arg, wh= ich means an increment of one, after the first use of the sizing key. I would prefer to keep the increment as I requested it, until I change it: C-5 C-x a a a a C-2 a a a ^^^ Change to more fine-grained control here, not before. Moving a frame around is probably a better example, since window resizing b= y increments of a line or char at a time rarely needs repetitions with large increments. Or think of window resizing by pixel increments instead of line/column incr= ements. You might well want to start with a large increment and switch to a smaller= one when you got closer to what you wanted. But the point is that where/when y= ou switch is based on what you see currently, not just automatically after the= first key hit. There is nothing to guarantee that your first try gets you close = enough to the point where you want to switch. IOW, I would give users the control interactively, not leave it up to some = hard rule. And I would let the increment be modal, so users need to do less specifying of the increment to use. They should, IOW, need to specify only *changes* in the increment.