From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Tweaking t-m-m to make room for d-s-m Date: Thu, 25 Mar 2010 12:27:50 -0400 Message-ID: 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 X-Trace: dough.gmane.org 1269536415 13249 80.91.229.12 (25 Mar 2010 17:00:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 25 Mar 2010 17:00:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 25 18:00:09 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 1NuqPg-0004Yv-Il for ged-emacs-devel@m.gmane.org; Thu, 25 Mar 2010 18:00:09 +0100 Original-Received: from localhost ([127.0.0.1]:49617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuqPf-0003RA-OJ for ged-emacs-devel@m.gmane.org; Thu, 25 Mar 2010 13:00:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NupuW-0002IM-0a for emacs-devel@gnu.org; Thu, 25 Mar 2010 12:27:56 -0400 Original-Received: from [140.186.70.92] (port=52304 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NupuU-0002GJ-Av for emacs-devel@gnu.org; Thu, 25 Mar 2010 12:27:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NupuS-0002Oz-JE for emacs-devel@gnu.org; Thu, 25 Mar 2010 12:27:54 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:51391) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NupuS-0002OC-GI; Thu, 25 Mar 2010 12:27:52 -0400 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o2PGRoDJ021035; Thu, 25 Mar 2010 12:27:50 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 86F8D3A0F4; Thu, 25 Mar 2010 12:27:50 -0400 (EDT) In-Reply-To: <87mxxw6c7b.fsf@lola.goethe.zz> (David Kastrup's message of "Thu, 25 Mar 2010 09:24:24 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3499=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:122661 Archived-At: > For example, there was one proposal that the equivalent of > delete-selection-mode was enabled for all marking operations (mouse, > shift-selection) that new user would be tempted to use, coming from > other editing environments. 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. Your suggestion to address that problem makes sense: 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. This reverts some part of the "enable t-m-m by default". I'm not completely sure it's a good solution, but it's one that I did consider back when we discussed enabling t-m-m (and I was happy not to have to resort to it ;-). One of the problems left with it is what to do for C-x C-x. Basically, we'd want two commands: one that swap point and mark, and one that activates the region. Currently C-x C-x does both. If we change C-x C-x to not activate the region any more, than that makes the C-SPC change more painful because then only C-u C-x C-x would be able to activate the region when you forgot to use C-SPC C-SPC and just hit C-SPC instead. OTOH 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. One point of attack might be to use C-x C-x C-x instead of C-u C-x C-x (a lot easier to type), but that's risky (hackish implementation almost unavoidable, plus conflicts with C-x C-x followed by some other C-x command).. 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. Stefan