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: Tweaking t-m-m to make room for d-s-m Date: Thu, 25 Mar 2010 16:56:31 -0700 Message-ID: <8D826837413D49AC968F80154D97F021@us.oracle.com> References: <87sk7pzqsp.fsf@ambire.localdomain><8739zps45s.fsf@mean.albasani.net><87mxxw6c7b.fsf@lola.goethe.zz> 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 1269561421 10241 80.91.229.12 (25 Mar 2010 23:57:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 25 Mar 2010 23:57:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 26 00:56:56 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 1Nuwux-0003ER-Dh for ged-emacs-devel@m.gmane.org; Fri, 26 Mar 2010 00:56:51 +0100 Original-Received: from localhost ([127.0.0.1]:48289 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nuwux-00071l-1Q for ged-emacs-devel@m.gmane.org; Thu, 25 Mar 2010 19:56:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nuwup-0006zp-D4 for emacs-devel@gnu.org; Thu, 25 Mar 2010 19:56:43 -0400 Original-Received: from [140.186.70.92] (port=47835 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nuwuo-0006yt-2T for emacs-devel@gnu.org; Thu, 25 Mar 2010 19:56:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nuwul-0003zQ-Ug for emacs-devel@gnu.org; Thu, 25 Mar 2010 19:56:41 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:56460) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nuwul-0003zH-OI for emacs-devel@gnu.org; Thu, 25 Mar 2010 19:56:39 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2PNubhu014707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Mar 2010 23:56:38 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2PNk81f025752; Thu, 25 Mar 2010 23:56:36 GMT Original-Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 112317681269561382; Thu, 25 Mar 2010 16:56:22 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Mar 2010 16:56:22 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrMPKFQt29FFMpkQDabWBujGcyb9gAJmIwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BABF834.0121: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:122679 Archived-At: > Here is how I see the situation: > - The DEL part of d-s-m would be acceptable right now > (i.e. generalizing mouse-region-delete-keys to non-mouse-activated > regions). > - The self-insert part of d-s-m is more problematic. The main problem > being the regions that are active "because of t-m-m" rather than > because the user wanted to activate the region. > > AFAIK the first point is decided and I'm just waiting for someone to > code it up. [ The main reason why I like it is that I dislike the > current implementation of mouse-region-delete-keys. ] > > For the second point, it's a real problem. Enabling self-insert > d-s-m without addressing the problem will lead to frequent > annoyances for some usage patterns. So, yes, we're back to > discussing how to make t-m-m work right, so that the region is > active iff the user wants it. So much for the famous user poll. ;-) > make C-SPC not activate the region (but let everything else > activate it), so that the region is only active when the user > really intended to activate it. Inappropriate assumption about user intention. Why assume that a user never intends to activate the region when s?he sets the mark using C-SPC? Sometimes I do and sometimes I don't. Setting the mark sets a navigation point, but it also sets one end of the region (by definition). If you want to select everything from here to there, and there is no ready command that does that (as does `C-M-@' for sexps, for example), then you want to set the mark here, move point there, and have the region activated. That's not an uncommon intention. Currently, you can avoid activating the region by using C-SPC C-SPC instead of C-SPC. And if you activate it and change your mind, you can use C-g to deactivate it. Not good enough? If you think C-SPC C-SPC is too much trouble, then switch the two: Let C-SPC set the mark without activating the region and C-SPC C-SPC set mark and activate. I could live with that, and I'll bet other d-s-moders could too. If t-m-mode is off, C-SPC C-SPC currently activates the region temporarily (i.e. without turning on t-m-mode). This change would just mean that C-SPC C-SPC always activates. But we can do better: Let users decide individually, by adding an option that says whether a single or a double C-SPC activates the region. The default could be either (double, if you like). That way, John Default can use C-SPC to set mark without activating and use C-SPC C-SPC to set and activate. And Jane Customize can use C-SPC to set and activate and C-SPC C-SPC to set without activating. Even better: The option could be defined so that one possible choice separates the navigational use from the region use completely. One of the possible values would thus mean that the key that sets mark and activates the region would not push it to the mark ring. For example, let the option value be a cons of two commands, the car being for C-SPC and the cdr for C-SPC C-SPC. The commands could be chosen from these: a. set mark and push to mark-ring (do not activate) b. set mark and activate (do not push to mark-ring) c. set mark, activate, and push to mark-ring A value of (a . b) would mean C-SPC sets mark for navigation only and C-SPC C-SPC uses it only for selection. A value of (c . a) would give today's behavior; (a . c) would swap today's keys. > One of the problems left with it is what to do for C-x C-x. Why not leave it as is? If t-m-mode is on, it activates; if off, it doesn't. The real concern, I think, is what happens when one uses C-SPC (see above). Or if C-x C-x C-g is really too much trouble, then add an option for this too. > we'd want two commands: one that swap point and mark, and one that > activates the region. Currently C-x C-x does both. Only if t-m-mode is on. > if we don't change C-x C-x, then users who want to > navigate to the mark get the region activated when they > didn't want it. Just use C-g (or whatever new key we choose for deactivation). And if someone never uses the active region, then by definition she never needs t-m-mode, and s?he can just turn it off. > This C-x C-x issue can also be solved if we can come up with a short > key-binding that activates the region (in which case C-x C-x doesn't > need to activate the region). Notice that we also have a need for > a short key-binding to deactivate the region (one that has fewer > side-effects than C-g, e.g. can be embedded in a keyboard macro). > So maybe the answer to all this is to find a "short" key-binding that > can toggle the region's active status. Sure, why not? That would combine well with my suggestion above about C-SPC vs C-SPC C-SPC. Let users choose the general behavior they want, and give them a key to toggle the current active/inactive state. And set the default behavior to whatever you want. Do I have a great key in mind for activate/deactivate? Dunno. How about `C-z' or `C-x C-z'? Does `suspend-frame' really need to be bound to both of those?