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: delete-selection-mode Date: Sun, 20 Apr 2008 14:06:05 -0700 Message-ID: <000e01c8a32a$5949ecb0$0200a8c0@us.oracle.com> References: <004a01c8a1a0$7215cdd0$0200a8c0@us.oracle.com> <878wz9btq8.fsf@jurta.org><85fxthy4qp.fsf@lola.goethe.zz> <87hcdxz9zr.fsf_-_@jurta.org> <87ve2cfk9x.fsf@stupidchicken.com><200804201931.m3KJVO4X008875@sallyv1.ics.uci.edu> <858wz8ux2w.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: ger.gmane.org 1208725581 19529 80.91.229.12 (20 Apr 2008 21:06:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2008 21:06:21 +0000 (UTC) Cc: 'Juri Linkov' , 'Chong Yidong' , emacs-devel@gnu.org, 'Stefan Monnier' , rms@gnu.org To: "'David Kastrup'" , "'Dan Nicolaescu'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 20 23:06:54 2008 connect(): Connection refused 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.50) id 1JngkI-0005Sh-1R for ged-emacs-devel@m.gmane.org; Sun, 20 Apr 2008 23:06:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jngjc-0002tO-RZ for ged-emacs-devel@m.gmane.org; Sun, 20 Apr 2008 17:06:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JngjY-0002t2-E6 for emacs-devel@gnu.org; Sun, 20 Apr 2008 17:06:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JngjW-0002sX-Qy for emacs-devel@gnu.org; Sun, 20 Apr 2008 17:06:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JngjW-0002sU-Mu for emacs-devel@gnu.org; Sun, 20 Apr 2008 17:05:58 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JngjP-000541-19; Sun, 20 Apr 2008 17:05:51 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m3KL5lrI015619; Sun, 20 Apr 2008 15:05:48 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m3K7b8t7026864; Sun, 20 Apr 2008 15:05:47 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3654694041208725544; Sun, 20 Apr 2008 14:05:44 -0700 Original-Received: from dradamslap1 (/141.144.120.206) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Apr 2008 14:05:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <858wz8ux2w.fsf@lola.goethe.zz> Thread-Index: AcijIAiuUsT9qr0JRpuNRI/2Rv7LyQABPetw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:95549 Archived-At: > Does really nobody have an idea how to improve the situation? Maybe > generalize mouse-deletion-mode (or what it is called) somewhat: I think > that I could tolerate an active region being deleted by typing DEL. I shudder to post on this topic, especially replying to you, David, but here goes. ;-) This is not an argument for choosing delete-selection-mode as the default behavior. It's a reply to your request for ideas for improvement. How about starting with delete-selection-mode (regardless of whether it would become the default behavior - let's assume not, here), and trying to improve it so that it plays better with your use cases? For example, you say that you don't want to delete the active region sometimes when you type text. Never? Sometimes? When? Maybe you can characterize the use cases better (to yourself at least). The delsel.el code might already provide some of the infrastructure for the improvements that would make it useful for you; I don't know. There is, for example, the ability to classify commands wrt their delete-selection-mode behavior (kill, yank, supersede, delete (t)) - the `delete-selection' property. This is pretty rudimentary currently. It might be one thing that could be tweaked - either by further classifying certain commands where you don't want the region deleted/replaced, or perhaps by adding more behavior types (besides kill, yank, etc.). Perhaps not just the current command but other parts of the current context and history could also usefully be taken into account. Dunno if it would help, but you might thus want to start with delsel, and improve it so it's not so obnoxious in your use cases. The code is short and simple. It could be a good place to improve things. Of course, "improve" is in the eye of the beholder. But I suspect that by characterizing your use cases and making the code respond better to them, we might even end up reducing the thrashing about preferred behavior, instead of increasing it. Call me an optimist. :-) Unlike the case of CUA selection and CUA mode, where one explicit goal is to stay very close to what non-Emacs users are used to, I think that improving delete-selection mode might just provide us the opportunity to come up with something great - something that is not only good for Emacs users of different habits but also much better than anything else out there. Call me a dreamer. On the default-behavior question, I'd say that we should consider the decision still open for future discussion. Whatever the current behavior is, I don't think we've come as close to a fix point as we can or need to. Which default behavior to use while the discussion goes on, I don't really care. I agree with David that we should try to see if we can't improve on the current alternatives a bit. That means discussing different use cases and things that bother us about each current alternative. That's frustrating as hell, granted, but if we take David's tack of looking to improvement of our options instead of just trying to sell each other on our current preference, we might just move the schmilblick forward a bit.