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: Selection changes in revno 100822 Date: Sun, 15 Aug 2010 16:01:33 -0700 Message-ID: <6FE4FA439FA244CAB0CC2474FA88923D@us.oracle.com> References: <834oeyv3ww.fsf@gnu.org> <87mxsqyp98.fsf@stupidchicken.com> <83zkwptyij.fsf@gnu.org> <4C66660D.3090603@swipnet.se> <83sk2htp82.fsf@gnu.org> <4C66A8C5.4040203@harpegolden.net> <83hbixte8c.fsf@gnu.org> <4C66D081.908@harpegolden.net> <838w48u9fg.fsf@gnu.org> <8739ugrniw.fsf@uwakimon.sk.tsukuba.ac.jp> <83sk2fspw6.fsf@gnu.org> <83r5hzskli.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1281913347 23842 80.91.229.12 (15 Aug 2010 23:02:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Aug 2010 23:02:27 +0000 (UTC) Cc: david@harpegolden.net, stephen@xemacs.org, jan.h.d@swipnet.se, cyd@stupidchicken.com, emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 16 01:02:23 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 1OkmDc-00050n-5j for ged-emacs-devel@m.gmane.org; Mon, 16 Aug 2010 01:02:23 +0200 Original-Received: from localhost ([127.0.0.1]:48746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkmDa-00089s-V6 for ged-emacs-devel@m.gmane.org; Sun, 15 Aug 2010 19:02:19 -0400 Original-Received: from [140.186.70.92] (port=34625 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkmDS-00089h-Qu for emacs-devel@gnu.org; Sun, 15 Aug 2010 19:02:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OkmDR-000482-3x for emacs-devel@gnu.org; Sun, 15 Aug 2010 19:02:10 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:62370) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OkmDQ-00047y-Tq; Sun, 15 Aug 2010 19:02:09 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7FN25pg001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Aug 2010 23:02:08 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7FAFvgh011205; Sun, 15 Aug 2010 23:02:04 GMT Original-Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 497501631281913297; Sun, 15 Aug 2010 16:01:37 -0700 Original-Received: from dradamslap1 (/10.159.221.253) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Aug 2010 16:01:36 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83r5hzskli.fsf@gnu.org> Thread-Index: Acs8tjdRx1T6HsxWQxSkmbcLLckp/AACihWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 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:128765 Archived-At: > > Express what will change for _users_, operationally, and > > why it is a good thing. Don't just say that the change is > > good and the traditional behavior is "bogus". > > You seem to confuse me with Stephen. I didn't say the old behavior > was bogus. No, I'm not confusing you with Stephen. I was not replying only to you personally. The point is that this discussion has not expressed what will change for users, in user terms. Some general opinions have been expressed wrt good/bad/ugly/bogus, without any clear expression of just what behavior changes are proposed. > > State clearly what is to be gained by changing. > > Consistency with other X apps, so it seems. Yes, we've gathered that much. But what will change, in operational terms, for Emacs users? Please tell us concretely and completely just what will change. (Again, the request is not necessarily for you personally.) > And I happen to agree that consistency with widely accepted > GUI standards is a Good Thing, in general. Probably everyone agrees that consistency is good, in general. Mom & apple pie - hoorah. The question is what is the +/-/good/bad _for Emacs_, with emphasis on specifics. What behavior changes, and what are their advantages and disadvantages. Emacs has always been _more or less_ consistent with some outside standards. It has also always differed to some extent from some outside standards. For the most part, any divergence from standards has not been accidental but intentional - that is my impression, at least. And over time, accidental divergences that have little negative impact have been corrected. IOW, other things being equal, sure, let's go for consistency with the outside world. What is most important wrt consistency is the _internal_ consistency within Emacs. And the devil is as always in the details: what changes and (for each change) what advantages. Complete consistency wrt an outside standard is not a necessary or sufficient aim. (Richard has expressed that elegantly on a number of occasions.) It should be only one consideration for us. What any potential changes do to users inside Emacs is much more important. So far, we know little about what changes are in store here. Lots of smoke and noise, little fire and signal. > > And say clearly and completely what the change is. > > That was said already. Let me repeat it (quoting David with slight > changes): > > clipboards aren't overwritten when you merely select text. > clipboards are overwritten when you cut/copy (C-w/M-w) > clipboard text is not inserted (pasted) when you click mouse-2. > clipboard text is inserted when you paste (C-y) > > primary selections are overwritten when you merely select text. > primary selections are not overwritten when you cut/copy > (C-w/M-w) (but > they've probably already just been overwritten because > you selected > text just before you cut/copied). > primary selections are inserted when you click mouse-2. > primary selections are not inserted when you paste (C-y) Sorry, that means little to me. Try saying something without referring to "primary" or "clipboard". Try describing the changes simply and _operationally_, in terms of user actions. See David's last mail replying to you for how. And please express them clearly as _changes_: Previously, when you did A and then B, the result was C. Now, the result will instead be D. That will be clear to all Emacs users, regardless of their knowledge of the X standard, primary selection, and clipboard. I repeat: "AFAICS we haven't yet gotten a simple description of the proposed changes, in terms of how they will affect users: use cases, pros & cons, what will change and why." > > That's my point: Make clear what the stakes are for users: What will > > be changed _from a user point of view_. And why it is a good thing: > > advantages, disadvantages. > > See this URL: > http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt I already saw it. See above: Please describe the proposed changes in terms of Emacs user actions. > It makes good sense wrt apps other than Emacs. When applied to Emacs, > IMO most of the reasons it gives for the above behavior are quite > lame, because Emacs has features this document doesn't consider. But > there's one reason that made perfect sense to me even wrt Emacs, > namely, that the "traditional" Emacs behavior with setting PRIMARY on > C-w/M-w has this problem: > > - you should be able to select text, then paste the clipboard over > it, but that doesn't work if the selection and clipboard are the > same > > IOW, if selecting text overwrites the clipboard, you cannot select and > then paste from the clipboard over the selection, because selecting > destroys the clipboard data. Please express it in Emacs terms. Give a recipe involving Emacs actions and not mentioning "clipboard" or "selection". For example: 1. Select some text with the mouse. (If important, break that down, but I'm guessing it is insignificant here just how selection is made using the mouse: drag, double-click, mouse-1 + mouse-3,...) 2. Hit C-y on the keyboard. ... (whatever) Show in that way what the problem is that you (pl) are trying to solve. Apparently, today there is a problem that people are running into (which involves trying to "paste the clipboard over selected text"). I'm not aware of the problem. Please describe it in simple terms. Start with emacs -Q, so we'll know just which modes are involved (e.g. delete-selection-mode? transient-mark-mode?...). > (It is ironical that all the heated discussion regarding the reasons > why the new behavior is "right" never brought up this reason, which > IMO is the only one that hits the nail on the head.) OK, so you have found a reason for the changes that convinces you. If you express it in Emacs terms (operationally), then perhaps some of the rest of us will also be convinced. Do I understand it? Maybe I do, but I think you (someone) should express it wrt Emacs actions. Might as well be very clear to everyone. What is the problem in practice? Is it that you want to select some text A, save that selection, select some other text B, and paste the saved text A to replace text B? Is that it? Is that the only reason for all of these changes - the reason, at least, that convinced you? If so, then I really don't see it as a significant problem. I already do that everyday, using the secondary selection - which has always been less ephemeral than and independent from the region/selection in Emacs. I often use that as a quick way to perform ad hoc replacements in Emacs. Doing that using the secondary selection does not prevent interaction between the mouse and the kill ring. And selection of the region with the mouse is done differently from selection of the secondary with the mouse (modifier keys), so the mouse can be used for each independently. And either can be used for yanking, independently (I mentioned that I have a second kill ring for the secondary). You might argue that the secondary cannot be used outside Emacs very easily, whereas the clipboard can. That's true, but I don't miss it in practice. I can easily paste from the kill ring to other apps, and I can easily transfer the secondary to the region in Emacs if I want to paste that outside Emacs. [For me: `C-M-y' yanks the secondary. `C-0 C-M-y' selects the secondary as the region. `C-1 C-M-y' turns the region into the secondary. (IOW, it defines the secondary using the keyboard.) `C-- C-M-y' swaps the secondary with the region. (IOW it puts the secondary where the region is now.) http://www.emacswiki.org/emacs/SecondarySelection#secondary-sel.el] In the few weeks that Emacs has been broken by the recent changes, I've already tried unsuccessfully many times to paste/yank text that I had selected previously, because mouse selection and pasting is now separate from keyboard selection and yanking. I cannot count the number of times that I've ended up pasting/yanking nothing or text other than what was expected. Including when trying to paste Emacs text outside of Emacs. > > It's amazing to me that we've gotten this far along with no > > proposal, discussion, and argument about pros & cons for users. > > FWIW, the above URL was posted here long ago. All the info you are > looking for is there. When it was posted long ago I read it. I'm still waiting for a simple Emacs recipe - a description in operational, user terms.