From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#6689: 24.0.50; No primary selection Date: Wed, 4 Aug 2010 17:19:14 -0700 Message-ID: References: <4C48B62A.2030709@harpegolden.net><106E1806DA3141AD99F7CC3D43D62BE8@us.oracle.com><87wrsnkvr3.fsf@stupidchicken.com><250BB20D91B04A20AE93C6D4C07C2004@us.oracle.com><83vd86trgq.fsf@gnu.org><2191175D5DFE4CECA85ECAB584756201@us.oracle.com><83lj92tdp4.fsf@gnu.org> <56E23E95B3284AAFA612902D84FFF581@us.oracle.com> <1DCC215D58A14474897137824F86BF4D@us.oracle.com> <4C59F644.50207@harpegolden.net> 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 1280968724 18408 80.91.229.12 (5 Aug 2010 00:38:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Aug 2010 00:38:44 +0000 (UTC) Cc: 6689@debbugs.gnu.org, cyd@stupidchicken.com To: "'David De La Harpe Golden'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 05 02:38:42 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1OgoTp-0005ku-CA for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Aug 2010 02:38:42 +0200 Original-Received: from localhost ([127.0.0.1]:41221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgoTo-0003Ng-R0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Aug 2010 20:38:40 -0400 Original-Received: from [140.186.70.92] (port=48012 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgoTK-00037d-Cu for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2010 20:38:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgoTI-0005WL-VL for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2010 20:38:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57467) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgoTI-0005WH-RR for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2010 20:38:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OgoBn-0004g0-1Y; Wed, 04 Aug 2010 20:20:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Aug 2010 00:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6689 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6689-submit@debbugs.gnu.org id=B6689.128096754717962 (code B ref 6689); Thu, 05 Aug 2010 00:20:03 +0000 Original-Received: (at 6689) by debbugs.gnu.org; 5 Aug 2010 00:19:07 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgoAs-0004ff-J0 for submit@debbugs.gnu.org; Wed, 04 Aug 2010 20:19:06 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgoAq-0004fI-JL for 6689@debbugs.gnu.org; Wed, 04 Aug 2010 20:19:05 -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 o750JWBj007660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Aug 2010 00:19:33 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o74MSaua019863; Thu, 5 Aug 2010 00:19:29 GMT Original-Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 486054491280967553; Wed, 04 Aug 2010 17:19:13 -0700 Original-Received: from dradamslap1 (/10.159.216.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 17:19:13 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C59F644.50207@harpegolden.net> Thread-Index: Acs0K/PgLa9IVDloSVe0QJ9GazAhjAAAHWJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C5A0392.02A6:SCFMA4539814,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 04 Aug 2010 20:20:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:39253 Archived-At: > > I hope all of these selection regressions will be fixed soon, so > > I can start using a recent Emacs build > > It is easy to revert to the old settings, as you must have > gathered by this stage. Great. Then please do revert Emacs to the "old" settings, and remove these regressions as soon as possible. Then we can all discuss possible improvements, if you like. > > However, I still cannot select text in one Emacs session > > and yank it into another Emacs session. E.g. select text > > with mouse in a buffer in one session, and try to yank it > > using mouse-2 into a buffer of another session. > > If you want emacs to copy the mouse selection to the windows > clipboard and emacs kill-ring, turn on mouse-drag-copy-region. If you do not want Emacs to do as it has done, then set the options that you want, to get the behavior you want for your own Emacs sessions. > If you want emacs to insert the windows clipboard/kill-ring > on mouse-2, do (global-set-key [mouse-2] 'mouse-yank-at-click) Ditto. If for your own use you want a different behavior from what Emacs has offered, then feel free to customize your copy of Emacs. What gives you the right to change the default Emacs behavior for everyone, to fit your preferences? Maybe your preferences are wonderful, but if you want to change the default behavior then you should ask emacs-devel, after making very clear what changes you propose. Honestly, I for one am open to being convinced that you have a better behavior in mind. You obviously know a lot about these things. But so far I've seen no clear proposal. All I've seen is behavior that is less useful AFAICT. Taking away the ability to copy & paste between Emacs sessions - by default - is a minus. I don't yet see a compensating plus, but I'm open to argument or demonstration. I speak only for myself, obviously, but I'm sure that others would also be interested in hearing your proposal. In the meantime, until a real discussion on the dev list and a decision to make the changes you want, please revert them. That should be easy, you say. > I already suggested to make the latter a boolean customisation so > that it can be more easily reverted again than by doing that. > http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01184.html > > > Eli has stated (IIUC) that nothing should have been changed > > for Windows, > > That is not necessarily true It's not? It seems to me that he did state that clearly. He said: In general, the behavior on MS-Windows does not need to change, because there's no primary selection on Windows. He did not say more than that AFAIK. He did not specify particular areas where he thinks it does need to change. Perhaps he will. > (unless you want emacs to continue to act weirdly on w32, and > believe me I get that you yourself do want that). This is not about what I want to do for my own use. If you want to put this in terms of what I want then put it in terms of what I want for _Emacs_, not in terms of what customized behavior I might want for myself. I do not want Emacs to change so that one can no longer select text in one Emacs session and yank it into another - and so on. Call that "weird" behavior if you like. It is the way weird old Emacs has behaved until now, and it is very useful. _I_ am not proposing to change the default Emacs behavior. Apparently you are. Or rather you're just changing it without a proposal to the community. > I did respond to Eli on that point. > http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01170.html You responded to him, but I do not see where he agreed with you. In any case, I do not agree that users (at least Windows users) should no longer be able, by _default_, to select text in one session and yank it into another session. Or at least I do not agree to such changes until I see a full proposal with a rundown of the pros & cons, including all the consequences. Maybe after weighing the pros & cons I will agree with you. For the moment I have only a poor idea of everything that is involved. All I see is changing behavior from build to build, and so far I see no advantage to any of those changes. It is not up to me to persuade you that those changes are bad. It is up to you, who are making changes, to persuade people that the changes are beneficial. If you persuade emacs-devel then I personally will either adopt the new or adapt by customizing to get back the old. It's not about my personal use. I said earlier that just making such changes willy nilly without consulting emacs-devel is not the right way to proceed. Someone replied that I should not react so quickly to such behavioral changes in recent builds, that they were just bugs that were introduced accidentally and would soon be corrected. But it's not clear to me just what is a temporary bug introduced by recent changes, and which will ultimately be fixed, and what is an intended change in behavior. None of this is clear. AFAIK you have not make a clear proposal describing the changes you want to make. Eli said: People who use Posix platforms are acutely aware of the difference between how Emacs used the clipboard and the selections, and how other applications do that. That's why they didn't see any reason to discuss the changes before making them. I would say that even people who do not use Posix currently should be brought into the loop. They might not use it, but they might still care about it and like to know about it. Why not describe the proposed changes so all can understand? In any case, wrt Windows I believe that Eli stated clearly that no behavior change was called for. For my part, I'm open to hearing about proposed changes, but I do not like what I see so far. And I do not think it is appropriate for people to discover changes without any prior discussion. If some changes just represent temporary bugs, no problem - we all introduce bugs now and then. But without a plan there is no way for us to know what is a bug and what is a new "feature".