From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#6774: Cut and paste with C-w/mouse-2 not working? Date: Fri, 13 Aug 2010 15:18:03 +0900 Message-ID: References: <4C55EF50.3080100@alice.it> <4C572AE6.7070104@harpegolden.net> <87wrs8ohnp.fsf@stupidchicken.com> <4C573A2A.3030007@harpegolden.net> <8762zphkaw.fsf@stupidchicken.com> <4C5B4E28.4090808@harpegolden.net> <87fwyr3glm.fsf@stupidchicken.com> <4C5C7915.7080407@harpegolden.net> <87hbj6jj7o.fsf@stupidchicken.com> <4C5DE6C7.5080706@harpegolden.net> <87vd7kcx52.fsf@stupidchicken.com> <4C6038B9.1090508@swipnet.se> <4C615BB9.8030905@swipnet.se> <4C61938B.5080302@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1281681537 18187 80.91.229.12 (13 Aug 2010 06:38:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Aug 2010 06:38:57 +0000 (UTC) Cc: cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 13 08:38:53 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 1Ojnui-0002JU-NB for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 08:38:49 +0200 Original-Received: from localhost ([127.0.0.1]:50720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ojnuh-0004QS-IW for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 02:38:47 -0400 Original-Received: from [140.186.70.92] (port=40018 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OjnuZ-0004Ok-UM for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 02:38:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OjnuX-0004vi-O3 for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 02:38:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38093) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OjnuX-0004va-MG for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 02:38:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Ojnab-0005r5-Vl; Fri, 13 Aug 2010 02:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2010 06:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6774-submit@debbugs.gnu.org id=B6774.128168024422496 (code B ref 6774); Fri, 13 Aug 2010 06:18:01 +0000 Original-Received: (at 6774) by debbugs.gnu.org; 13 Aug 2010 06:17:24 +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 1OjnZz-0005qn-Q5 for submit@debbugs.gnu.org; Fri, 13 Aug 2010 02:17:24 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OjnZx-0005qi-9F for 6774@debbugs.gnu.org; Fri, 13 Aug 2010 02:17:22 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o7D6I57P003079; Fri, 13 Aug 2010 15:18:05 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o7D6I50w019765; Fri, 13 Aug 2010 15:18:05 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id o7D6I3o7002556; Fri, 13 Aug 2010 15:18:03 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1Ojnad-00004x-7r; Fri, 13 Aug 2010 15:18:03 +0900 In-Reply-To: (message from Stefan Monnier on Thu, 12 Aug 2010 18:09:28 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 13 Aug 2010 02:18:01 -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:39456 Archived-At: In article , Stefan Monnier writes: >>> Putting it in set_point_both would be much worse than on >>> post-command-hook (set-point-both is a very low-level function, >>> triggered in many more cases than just moving the cursor). > > If a test to check if we have to newly own the PRIMARY > > selection is trivial, there should be no problem. > And what do we do with the result of the check? This function too > low-level to be able to perform the "set PRIMARY" from there. I don't know your criteria for "too low-level". > > Another candidate for checking that is somewher near here in > > command_loop_1 () (around line 1818). > > finalize: > > if (current_buffer == prev_buffer > > && last_point_position != PT > > && NILP (Vdisable_point_adjustment) > > && NILP (Vglobal_disable_point_adjustment)) > > { > > This place is similar to post-command-hook, but we can avoid > > unnecessary Lisp calls in many cases. > Yes, that's like post-command-hook. > I'm more worried about the semantics than about the performance impact. > Doing the "set PRIMARY" from C-w and friends is much easier and robust. > Doing it in S-right is OK as well. Doing it in forward-char is not and > doing it for `right' (by rebinding it to a new command) doesn't sound > too attractive. I was wordering how "S-right" (and S-C-f, etc) are implemented. So, I read the code and was surprized by its complication. For every S-C-f, read_key_sequence sets this-command-keys-shift-translated to t and read_key_sequence_cmd to forward-char. Next, Fcall_interactively calls handle-shift-selection, and it sets transient-mark-mode to a special cons (only . ...). At last, command_loop_1, after execuing forward-char, does some check and eventually calls x-set-selection. The detail is more complicated. I don't claim that the code is too complicated. Perhaps, there's no other way; I don't know. Anyway, we are already doing that for forward-char. Doing a little bit more in command_loop_1 (and/or maybe in Fcall_interactively) shouldn't be a problem. It doesn't change the semantics of forward-char (as well as handling of S-C-f like above doesn't change the semantics). At least, command_loop_1 is not "too low-level" for calling x-set-selection. And, first of all, from a user point of view, as these two highlights a region exactly the same way (with the default setting), (1) S-C-n (2) C-@ C-n it's very confusing that they behave differently as to selection. --- Kenichi Handa handa@m17n.org