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: CUA-mode features and documenation Date: Mon, 18 Feb 2008 07:52:33 -0800 Message-ID: <001b01c87246$473238d0$e140908d@us.oracle.com> References: <000d01c86c82$700dccc0$7051908d@us.oracle.com><200802121430.m1CEUc6k013361@sallyv1.ics.uci.edu><002601c86d8a$a0454db0$405a908d@us.oracle.com> <87tzkdnkee.fsf@kfs-lx.rd.rdm><87ir0sonaa.fsf_-_@kfs-lx.rd.rdm><200802131623.m1DGNrls003614@sallyv1.ics.uci.edu><87odakwl2r.fsf@jurta.org> <87myq4saw1.fsf@catnip.gol.com><878x1ov227.fsf@jurta.org> <878x1os6mt.fsf@catnip.gol.com><47B39231.8010108@gmail.com> <200802151711.m1FHB3Y3008798@sallyv1.ics.uci.edu><004e01c8718f$afa8dac0$2d58908d@us.oracle.com> <87mypyz8dy.fsf@kfs-lx.rd.rdm> 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 1203350069 31523 80.91.229.12 (18 Feb 2008 15:54:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2008 15:54:29 +0000 (UTC) Cc: rms@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org, juri@jurta.org, 'Dan Nicolaescu' , miles@gnu.org To: "'Kim F. Storm'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 18 16:54:52 2008 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 1JR8KK-0008AG-15 for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2008 16:54:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JR8Jp-0007Bx-FC for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2008 10:54:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JR8Jk-00079X-3M for emacs-devel@gnu.org; Mon, 18 Feb 2008 10:54:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JR8Jj-00079K-E1 for emacs-devel@gnu.org; Mon, 18 Feb 2008 10:54:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JR8Jj-00079F-70 for emacs-devel@gnu.org; Mon, 18 Feb 2008 10:54:07 -0500 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 1JR8Jb-0007ai-K4; Mon, 18 Feb 2008 10:53:59 -0500 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 m1IFraMT001629; Mon, 18 Feb 2008 08:53:36 -0700 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 m1I5PBCA020636; Mon, 18 Feb 2008 08:53:35 -0700 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3580051041203349931; Mon, 18 Feb 2008 07:52:11 -0800 Original-Received: from dradamslap1 (/141.144.64.225) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Feb 2008 07:52:11 -0800 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87mypyz8dy.fsf@kfs-lx.rd.rdm> Thread-Index: AchyNHeSnWR1a+GiQwibCXD5rFcoAQADe9Ug 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:89484 Archived-At: > > I think we need to keep giving users a choice about this (having > > S- set mark if the region is inactive). That could be > > done by keeping both D S mode and CUA selection mode, or (simpler?) > > by adding a user option and keeping only one of them. > > You completely lost me there ... > > If you commonly use C-SPC to start the region, why would you _ever_ > use the shifted arrow keys to extend the region, when the unshifted > arrow keys extends it just as well (that's how the region normally > works) ?? Right. My point was that from what you described, the automatic C-SPC is the only difference, since you can use C-SPC S- in delete-selection-mode, versus just S- in cua-selection-mode. If the only thing cua-selection-mode adds wrt delete-selection-mode is the automatic C-SPC, then let's just make that an option. > So if you are not in the habit of using shift-select, you can use > cua-selection-mode just like delete-seletion-mode. Or, if you are not in that habit, then you can also use delete-selection-mode just like cua-selection-mode. ;) Modulo the unnamed "probably more stuff". > > I don't know about the "probably some more" stuff - perhaps > > we should look into that. If there is in fact no more, then > > just adding an option to D S mode for S- to set mark > > (if inactive) would be sufficient. We could then drop CUA > > selection mode. > > Huh? "just adding" ? That's not trivial! OK. > Since delete-seletion-mode functionality is already > integrated in cua-mode, while shift-select support is > absent from delete-seletion-mode, it would be > more natural to make delete-seletion-mode be a sub-mode of > cua-mode, rather than the opposite (it just needs an option > cua-enable-shift-select - default on). That's fine with me. I already stated that either would be fine. But what about the "probably more stuff" you referred to? What's involved there? You say now that all you would need to get delete-selection-mode behavior is to turn off a proposed option that automatically sets mark when you use the arrow keys. But what about the other stuff? What is it, and how would a user turn it off, to get delete-selection-mode behavior? > > Question (not proposal): Assuming we keep CUA selection > > mode, would it be clearer to change its name, to avoid > > confusion with CUA mode? I imagine that CUA selection mode > > is a perfectly accurate name, in that it presumably > > implements the selection part of IBM's Common User Access > > (http://en.wikipedia.org/wiki/Common_User_Access). > > Why rename something which is a "perfecty accurate name" ? For the reason I gave in the very next paragraph, which you omitted: Even so, (1) the name might lead to some confusion with CUA mode, and (2) it's not obvious to most people what "CUA" is. That ignorance is probably OK for CUA mode, since you need to read the doc anyway to find out what it's all about (lots of features), and "Common User Access" refers to more than just selection. But for CUA selection mode, we might look for a better name. IOW, even though "common user access selection mode" accurately describes this as the selection mode of Common User Access, the term can be misleading (confusion with cua-mode) or inadequate (ignorance of Common User Access). BTW, there is no need to get defensive about it. I don't really care how we handle the overlap or the name. I just pointed out some overlap and some potential user confusion. > > Looking at various Emacs Wiki entries, I suspect there is a > > fair amount of confusion for newbies among (1) transient mark mode, > > (2) delete selection mode, (3) PC selection mode, and (4) CUA > > selection mode. > > The confusion must be because experienced users try to > convince the newbies NOT to enable full cua-mode (with the > C-x C-c mappings)... I think you are being defensive. "The confusion must be"? What evidence do you have either that experienced users are doing that or that that "must be" the reason that newbies are confused about this? > To avoid confusion - just enable cua-mode (in full) and Emacs > behaves like (something missing there?) Nothing wrong with such a suggestion, and I think that has already been communicated to users, both on the wiki and in the Emacs doc. > >> If we want to promote it that way, we should choose a better > >> name that CUA Selection mode, because most people won't know > >> what "CUA" means. > > Call it delete-selection-mode then ! Call it what you like. I have no axe to grind here. I already said that "delete-selection-mode" is also not a great name: Note that "delete selection" mode is also not the ideal name for what it does. It is really a "replace selection" mode. You can type to replace the active region, and deletion is just replacement by nothing. But then, even "replace selection" doesn't convey the ability to extend the active region using S-. (or using just )