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: Fri, 23 Jul 2010 07:57:26 -0700 Message-ID: <2191175D5DFE4CECA85ECAB584756201@us.oracle.com> References: <4C48B62A.2030709@harpegolden.net> <106E1806DA3141AD99F7CC3D43D62BE8@us.oracle.com> <87wrsnkvr3.fsf@stupidchicken.com> <250BB20D91B04A20AE93C6D4C07C2004@us.oracle.com> <83vd86trgq.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 1279897657 21398 80.91.229.12 (23 Jul 2010 15:07:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Jul 2010 15:07:37 +0000 (UTC) Cc: cyd@stupidchicken.com, 6689@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 23 17:07:33 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 1OcJqW-0008M2-9w for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jul 2010 17:07:32 +0200 Original-Received: from localhost ([127.0.0.1]:37872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OcJqV-0006wh-AT for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jul 2010 11:07:31 -0400 Original-Received: from [140.186.70.92] (port=45004 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OcJqQ-0006wc-MQ for bug-gnu-emacs@gnu.org; Fri, 23 Jul 2010 11:07:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OcJqP-0003U3-EC for bug-gnu-emacs@gnu.org; Fri, 23 Jul 2010 11:07:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42342) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcJqO-0003Ty-S9 for bug-gnu-emacs@gnu.org; Fri, 23 Jul 2010 11:07:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OcJiI-0004Rm-5Q; Fri, 23 Jul 2010 10:59:02 -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: Fri, 23 Jul 2010 14:59:02 +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.127989713717088 (code B ref 6689); Fri, 23 Jul 2010 14:59:02 +0000 Original-Received: (at 6689) by debbugs.gnu.org; 23 Jul 2010 14:58:57 +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 1OcJiC-0004RZ-EW for submit@debbugs.gnu.org; Fri, 23 Jul 2010 10:58:56 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcJi9-0004RU-Ev for 6689@debbugs.gnu.org; Fri, 23 Jul 2010 10:58:54 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6NEwnd8005480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jul 2010 14:58:50 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6NEwkDb015894; Fri, 23 Jul 2010 14:58:48 GMT Original-Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 452793301279897055; Fri, 23 Jul 2010 07:57:35 -0700 Original-Received: from dradamslap1 (/10.159.216.179) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Jul 2010 07:57:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83vd86trgq.fsf@gnu.org> Thread-Index: AcsqUu/bsZXwqQjeScq2l223gJWPBQAIDi+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C49AE29.00A1:SCFMA4539814,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Jul 2010 10:59:02 -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:38825 Archived-At: > Whatever changes were made, no one meant to make them on Windows. Good to hear. If similar symptoms appear on other platforms (dunno), then I would hope they would be removed from there as well. > The motivation was behavior on Posix systems > wrt the clipboard and the primary selection. As I wrote elsewhere, I > don't see any reasons to change the behavior on Windows, which lacks > the primary and secondary selections, and has just the clipboard. > > Can you give a concise list of problems in the new behavior on > Windows? I gave concise, clear descriptions - see the original bug reports. Do you want me to repeat the recipes? Here again is the one for this bug report (#6689): > emacs -Q > > In another Emacs session, select some text in any way > and hit `M-w'. > > Click mouse-2 in the new Emacs session. You get the > error "No primary selection". For example, try to yank the > text into the prompt at `report-emacs-bug' using mouse-2. > Note: C-y works, but mouse-2 does not work. What part of that description do you not follow? Here's the other original report (#6694) recipe (again): > I click mouse-1 at the left of some text and then > mouse-3 at the right of it, to select it (a Lisp symbol). > Then I try to yank it using `mouse-2': > > Debugger entered--Lisp error: (wrong-type-argument > char-or-string-p #) > mouse-yank-primary((mouse-2 (# > 4906 (392 . 488) 12477031 nil 4906 (49 . 33) nil (224 . 9) > (8 . 14)))) > call-interactively(mouse-yank-primary nil nil) > > Yanking it with C-y works OK. So the problem is not with > what was copied but with `mouse-yank-primary'. I amended that within a couple of minutes as follows: > Correction: Clicking mouse-1, then mouse-3 apparently > does *not* copy the selection to the kill ring.... > Without M-w, C-y doesn't work either (after selecting using > mouse-1, 3). Is there something in that report that is not clear to you? I don't have any more information about it. That's all I did and that's all I saw. Those are the two bugs that I reported. There are several other bug reports, reported by others, that also have to do with mouse selection/copying/killing/yanking. It sounded to me like they were seeing similar things, but I cannot speak for them or their platforms. Clearly, someone has been messing with the mouse recently ;-), and users on various platforms are reporting problems. I am relieved to hear people such as yourself agree that this changed behavior represents a bug and not an intentional change. That was *not* obvious, given some of the rationalization and discussion of needed "improvements" in this area. That was one of the points I made: there was no clear proposal for a specified change, followed by discussion and agreement. Just some half-discussion and then some code changes. How to know whether a given behavior change observed is part of what was intended for these "improvements" that were half talked about or just an implementation mistake? I don't know clearly what the proposed change _is_, so it's hard to judge the real change that occurred - was it intended or not? I'm glad to hear you say it was not ("no one meant to make them on Windows"). It's still not clear (to me) what _problems_ the recent changes (unintentional or intentional) were an effect (side-effect or intended effect) of trying to fix. What's the perceived problem or limitation that motivated such changes? I'm using Windows now, but I'm also interested in proposed changes that will affect Emacs on other platforms. It's not clear to me what changes are in store for us - on Windows and elsewhere. The dev process is itself broken in this regard, IMO. We should see a clear proposal, discuss it, and agree on it, before an attempt is made to implement it. Without that, there is no way to know whether some change is part of the plan or a bug.