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: Re: delete-selection-mode Date: Thu, 25 Mar 2010 22:48:49 -0400 Message-ID: References: <22603146-A346-4FC2-8D74-5D6047865C3A@mit.edu> <87r5nf8s7q.fsf@siart.de> <87pr2ygbii.fsf@lola.goethe.zz> <87tys9180s.fsf@catnip.gol.com> <87ocih158i.fsf@catnip.gol.com> <874ok7bhse.fsf@lola.goethe.zz> <87fx3r10ec.fsf@stupidchicken.com> <87d3yv7zzy.fsf@lola.goethe.zz> <87634n0xnn.fsf@stupidchicken.com> <87fx3rc5p0.fsf@mail.jurta.org> <87vdck1dyt.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269571746 2929 80.91.229.12 (26 Mar 2010 02:49:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Mar 2010 02:49:06 +0000 (UTC) Cc: Juri Linkov , David Kastrup , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 26 03:49:01 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 1NuzbZ-0006rM-II for ged-emacs-devel@m.gmane.org; Fri, 26 Mar 2010 03:49:01 +0100 Original-Received: from localhost ([127.0.0.1]:41518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuzbY-0007xU-V7 for ged-emacs-devel@m.gmane.org; Thu, 25 Mar 2010 22:49:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuzbS-0007vP-SD for emacs-devel@gnu.org; Thu, 25 Mar 2010 22:48:54 -0400 Original-Received: from [140.186.70.92] (port=54639 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuzbR-0007uq-CN for emacs-devel@gnu.org; Thu, 25 Mar 2010 22:48:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuzbQ-0003hh-88 for emacs-devel@gnu.org; Thu, 25 Mar 2010 22:48:53 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29475 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuzbO-0003hN-88; Thu, 25 Mar 2010 22:48:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALe9q0tFpYrY/2dsb2JhbACbKXS+SIR9BIsd X-IronPort-AV: E=Sophos;i="4.51,311,1267419600"; d="scan'208";a="59083254" Original-Received: from 69-165-138-216.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.216]) by ironport2-out.pppoe.ca with ESMTP; 25 Mar 2010 22:48:49 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4913185F0; Thu, 25 Mar 2010 22:48:49 -0400 (EDT) In-Reply-To: <87vdck1dyt.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 25 Mar 2010 13:57:30 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:122684 Archived-At: >>> What do you think about marking commands that should delete the active >>> region with a new interactive character (like "^" is used to call >>> `handle-shift-selection'), so e.g. a new function `handle-delete-region' >>> could delete the active region before running a command? >> Sounds very good, indeed, > Isn't this redundant with the idea of replacing mouse-region-delete-keys > with a more general variable that affects all active regions? That > sounds more appealing than assigning more interactive codes. No, what I want is to replace the code that implements the feature linked to mouse-region-delete-keys by new code which implements a similar feature that covers more cases (not linked to mouse-selection). Whether that new code uses a variable like foo-region-delete-keys is an "implementation detail". And I think relying on keys (as is done currently by mouse-region-delete-keys), or on symbol names (as is done currently by d-s-m) is wrong: the behavior should depend on the actual command, so it needs to be part of the command's definition, which basically means part of its interactive spec. Again, the reasoning is exactly the same as the one that lead to the "^" for shift-select. Stefan