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: Fri, 24 May 2013 08:55:11 -0700 (PDT) Message-ID: <743145c2-9a1b-4db6-b964-a2cd00276c7e@default> References: <87mwrombc3.fsf@mail.jurta.org> <87r4gyondh.fsf@mail.jurta.org> <6CA0C904-94F7-4ECF-A8E0-BC78844E5348@mit.edu> <8963bd95-a5fc-4f2a-b8fc-40dbc7074809@default> <58e2bc51-1857-432b-b79f-f32515225b72@default> <87ppwht1vl.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1369410924 27860 80.91.229.3 (24 May 2013 15:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 May 2013 15:55:24 +0000 (UTC) Cc: chad , Stefan Monnier , "emacs-devel@gnu.org Development" To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 24 17:55:23 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 1UfuKv-0007vd-Vx for ged-emacs-devel@m.gmane.org; Fri, 24 May 2013 17:55:22 +0200 Original-Received: from localhost ([::1]:51023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfuKv-0007Pb-M3 for ged-emacs-devel@m.gmane.org; Fri, 24 May 2013 11:55:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfuKr-0007P3-Ra for emacs-devel@gnu.org; Fri, 24 May 2013 11:55:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfuKp-0001V5-Hu for emacs-devel@gnu.org; Fri, 24 May 2013 11:55:17 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:46463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfuKp-0001Un-9o for emacs-devel@gnu.org; Fri, 24 May 2013 11:55:15 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4OFtCAu006231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 May 2013 15:55:13 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4OFtBf5006155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2013 15:55:12 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 r4OFtBhD006151; Fri, 24 May 2013 15:55:11 GMT In-Reply-To: <87ppwht1vl.fsf@uwakimon.sk.tsukuba.ac.jp> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:159770 Archived-At: > (1) Discoverability. Auto-acceleration=20 It's undefined, so far. Hard to defend or criticize something still pie-in= -the-sky. But my crystal ball and experience whisper to me that "automatic" too often= misses the mark and does not really DWIM. On the other hand, _direct manipulation_ is all about user control, with immediate feedback. > would likely happen to me frequently, so I'd learn it. > (Maybe not learn to use it, but learn to avoid it, at least.) Avoiding an "automatic" do-it-all solution is one way to try to deal with i= t. But it does not solve the problem. > "C-u C-u C-x } } C-3 }" is not something I would likely try > on my own, nor would I find it easy to remember if I read > about it in passing. No need to remember anything. The default behavior (no prefix arg) provide= s a fine-tuning value (e.g. an increment) of 1. And trying C-u at the outset, which is pretty simple and discoverable, quic= kly shows you what it does: provides a larger increment for subsequent stepping= . Just stop and start again with the prefix key, if you like, to use a differ= ent increment for subsequent steps. Also obvious. And if you _happen_ to use a prefix arg also before one of the final-key occurrences... WYSIWYG - immediately. This is just a shortcut so you don't= have to start again with the prefix key. Readers of the doc string or curious experimenters will quickly discover th= e shortcut. And others are not handicapped without the shortcut: they can just hit the = prefix key again, giving it a different prefix arg to change the increment size. IOW, if you don't happen to stumble upon all the available behaviors, it's = likely you'll continue using the default increment, which means fine-tuning all th= e time. Or you'll figure out only the initial prefix arg, so will quit after N uses= and start again without a prefix arg to fine-tune. > (2) Consistency. I can't think of any other case where an infix key > controls the behavior of a command. There is no "infix" key anywhere here. There are just keys, bound to vario= us commands. And each key accepts a prefix arg and does something with it. The only thing different from usual here is that the default value of the p= refix arg is the last used prefix arg, instead of 1. And that is already what we do for C-x C-(+|-), except that we don't let yo= u change the prefix arg along the way. The arg you use initially continues t= o be used for each subsequent step. We do NOT revert you to the default increme= nt size for steps after the first. You continue to increment/decrement using = the same increment size for all steps. That's the approach I recommend. With the added feature that you can, if y= ou like, change the increment on the fly, without having to start over with the pref= ix key. > (3) Usability. Some people, like you, can estimate pretty well > whether you need C-2 or C-3. Others can't, and would need to > calculate, possibly costing more time than they save. Auto- > acceleration has no such cost of computation. No, you miss the point. This is direct manipulation. Typically each such resizing, moving, etc. command/key has its opposite: `right' cancels `left' etc. Overshoot? Just come back. Come back less or more, as needed. There is nothing to "estimate". Just do it and see immediately the effect, adjusting on the fly as needed. This is typical of any command that is repeatable and provides incremental = adjustment. A different but similar approach is used in DoReMi, which lets you incremen= tally change all kinds of things. There, instead of a prefix arg, there is a def= ault increment size, and using the `Meta' key with the usual incrementing keys (= e.g. `up', `down', `left', `right') boosts the default increment by a factor. So if you want to move your frame quickly across the screen then you hold d= own `M-' while you hold down `right'. If you want to slow down you release `M-= '. If you go too far then you use `left' to come back. Simple, even obvious. The point is that it is trivial to "discover" how to incrementally adjust s= omething, including taking advantage, when you want to, of any scaling/boosting/accel= erating. This is no more difficult to "learn" or discover than sliding a scroll-bar = thumb with your mouse pointer. > (4) Economy. The advantage of user control is smaller than you > suggest, I believe. Anything bigger than C-1 will cause you to > miss the target half the time or more. Simply not true. Where do you get that "half the time or more"? And what = does "miss the target" even mean here, precisely? We're talking about incremental adjustment. If I want to move an Emacs fra= me downward so that its bottom edge precisely aligns with the top of another f= rame (just as an example), that edge coincidence is presumably your "target". I= t is obvious and simple to do this incrementally. If you want to move the whole= distance using a tiny increment (e.g. 1 pixel at a time), you can do that. But if y= ou want to move most of the distance using a larger increment then you can do that = too. And if you overshoot (and you likely will, when in a final "docking" maneuv= er) then you just move back (and forth, if necessary, until you get it right). This is so simple as to make any description of it overkill. But hopefully= it is clear now? =20 > Sometimes people will need > to correct for overshooting, which means either starting over with > the inverse command or using a negative count. And even if they > undershoot they need to switch to C-1. You make over/undershooting sound like some kind of error. It is in fact t= he _normal_ way we interact with our environments (and even with ourselves). You cannot sit down or stand up or take a step without making over/undersho= ot adjustments. And no, I do not understand your statement about starting over. > I don't want it badly enough to write the code, but I suspect more > users will find it useful than the UI you propose. Both are valid > proposals and worth experimenting with. Yes to the idea that experimenting is helpful. If you want to experiment with incremental adjustment (if not the same pref= ix-arg design), here are a few places to start: * frame-cmds.el: commands such as `move-frame-(down|up|right|left)', `(enlarge|shrink)-frame(-horizontally)' http://www.emacswiki.org/emacs-en/download/frame-cmds.el * doremi-frm.el, doremi-cmd.el: any of the commands (increment face/frame c= olors, frame/font sizes, etc.) http://www.emacswiki.org/emacs-en/download/doremi-frm.el http://www.emacswiki.org/emacs-en/download/doremi-cmd.el http://www.emacswiki.org/cgi-bin/wiki/DoReMi Even in vanilla Emacs, just consider adjusting text size using C-x C-(-|+),= with and without a prefix arg. A prefix arg here is "modal" in the sense that t= he initial prefix arg you give is passed on to each subsequent +/-, instead of= reverting to an increment of 1. You cannot, however, change the increment along the = way (which is the additional feature I proposed in the current context). Or even just using `M-f' and `C-f' to move across text to your "target", co= ming back with `(M|C)-b' if you overshoot, etc. Here, like the DoReMi booster-key ca= se, there are separate keys for different size increments. A prefix arg here control= s not the increment size but the number of jumps. Really not a big deal at all. All of these different ways of incrementally= adjusting something provide easy ways to fine-tune, including adjusting for over/unde= rshoot.