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 15:28:36 -0700 Message-ID: <001101c8a335$e089caa0$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> <000e01c8a32a$5949ecb0$0200a8c0@us.oracle.com> 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 1208730549 777 80.91.229.12 (20 Apr 2008 22:29:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2008 22:29:09 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org, juri@jurta.org, dann@ics.uci.edu, monnier@iro.umontreal.ca To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 00:29:41 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 1Jni2W-0004NA-Fi for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 00:29:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jni1q-00076U-Vp for ged-emacs-devel@m.gmane.org; Sun, 20 Apr 2008 18:28:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jni1m-00074l-UV for emacs-devel@gnu.org; Sun, 20 Apr 2008 18:28:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jni1m-00074F-D7 for emacs-devel@gnu.org; Sun, 20 Apr 2008 18:28:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jni1m-000744-7H for emacs-devel@gnu.org; Sun, 20 Apr 2008 18:28:54 -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 1Jni1b-0001z2-Ki; Sun, 20 Apr 2008 18:28:44 -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 m3KMSe7U000432; Sun, 20 Apr 2008 16:28:40 -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 m3K7b8u5026864; Sun, 20 Apr 2008 16:28:39 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3653864451208730495; Sun, 20 Apr 2008 15:28:15 -0700 Original-Received: from dradamslap1 (/141.144.120.206) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Apr 2008 15:28:15 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcijLaeNjViXbnRnRa+JWjr6+OV9QQAAr0vw 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:95563 Archived-At: > > 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? > > I think the only way to have the feature and leave everyone mildly > happy is to separate the ``deletable'' selection from the normal Emacs > region. That is, introduce a new notion, let's call it ``selection'', > that is a portion of text which is defined by dragging the mouse or > moving the cursor with the Shift key pressed. Let then this > ``selection'' be deleted as in other GUI apps. This is what newcomers > expect, they don't know about the region, so won't expect it to behave > like ``selection''. > > Keeping our hands off the region will avoid the risk of infuriating > long time Emacs users. I'm one such long-time Emacs user. And I'm not so concerned about newcomers and what they might be used to - we have CUA for that. As I said, this is not about the default behavior, so no one should feel threatened about imposition. That question should remain open - we can return to what we had as default in Emacs 21 for all I care. I'm interested here not in newbie-soothing but in making the alternatives better, as David suggested. I think that delete-selection mode could become the basis of something that most Emacs users (including most old-timers) would prefer. I think we can do better, but I don't have a concrete suggestion, partly because I don't have a good feel for the use cases and perceived problems. FWIW, I would never use a selection such as you describe. That's not what is available with delete-selection mode. I want to be able, when I want, to use the _region_ in delete-selection ways: delete or type to replace. We can determine contexts when that is not desirable, and exclude them. We can provide user options for customization. The problem, as I see it, is not that delete-selection deletes or replaces the region. It is that it sometimes does so when someone doesn't want it to. To me, the starting point for a superior Emacs notion of active area that is visible, deletable, killable, and replaceable should be the _region_, because of all of the other wonderful region properties that Emacs offers. I _like_ the fact that delete-selection mode uses the region. I take advantage of that all the time. That's why I suggest starting with it - it is a concept and behavior made for Emacs, not for merely respecting some non-Emacs conventions. I think I understand David's concerns, at least generally, and I suspect we could address them. I don't see a fundamental contradiction between the notion of Emacs region and a behavior of sometimes having the region be deleted or replaced by text that you type. The problem, as I hear it, is that there are other times when you don't want that to happen. So let's characterize those patterns. It's likely that after improving delete-selection mode to take such things into account, different users will want to use it differently. I might want to have type-to-replace in some of the contexts where David does not want that. Users should be able to customize the behavior, obviously. But the basic infrastructure is what we should start with and improve first. If properties on command symbols is too simplistic for the kind of control needed, then let's discover what we really need and make the infrastructure satisfy it. > It will also avoid the need to produce some > kind of heuristics for figuring out issues like this one: > > > 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). > > I feel that any such heuristics, even if we succeed in coming up with > it, will be a hopelessly fragile pile of twisted little passages all > alike, that will break on us all the time and cause infinite > maintenance headaches. Such a foreboding prospect - you certainly know how to scare. It sounds like you're giving up before the first shadow of a characterization has been attempted, throwing up your hands at the first complaint that delete-selection mode deleted the region when someone didn't want that. We have lots of code in Emacs that deals with various contexts or conditions. It's not as if the delete-selection code was already complex. It's rudimentary. How do you know that a few healthy tweaks might not take care of the main problems some people encounter? I'm the first one to argue against complex DWIM attempts - you've heard me before about that (quitting view mode, combined behaviors for TAB, etc.) - I am not a great fan of DWIM. In this case, however, I suspect that there might not be a lot needed, to take care of the perceived problems. I could be wrong. You, on the other hand, foresee a nightmare. But how to know without at least trying, taking a look at the existing code?