From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#6774: Cut and paste with C-w/mouse-2 not working? Date: Fri, 13 Aug 2010 12:40:33 +0200 Message-ID: References: <4C55EF50.3080100@alice.it> <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 1281697732 26083 80.91.229.12 (13 Aug 2010 11:08:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Aug 2010 11:08:52 +0000 (UTC) Cc: cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it To: Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 13 13:08:50 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 1Ojs7z-0003Dj-Vv for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 13:08:49 +0200 Original-Received: from localhost ([127.0.0.1]:43340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ojs7y-0008CZ-7M for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Aug 2010 07:08:46 -0400 Original-Received: from [140.186.70.92] (port=40638 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ojs7r-0008BL-DC for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 07:08:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ojs7q-0004FG-1Z for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 07:08:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44060) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ojs7q-0004FA-03 for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2010 07:08:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OjrgA-0007ey-Ly; Fri, 13 Aug 2010 06:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier 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 10:40:02 +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.128169598829429 (code B ref 6774); Fri, 13 Aug 2010 10:40:02 +0000 Original-Received: (at 6774) by debbugs.gnu.org; 13 Aug 2010 10:39:48 +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 1Ojrfv-0007ec-57 for submit@debbugs.gnu.org; Fri, 13 Aug 2010 06:39:47 -0400 Original-Received: from impaqm1.telefonica.net ([213.4.138.1]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ojrfs-0007di-Gf for 6774@debbugs.gnu.org; Fri, 13 Aug 2010 06:39:45 -0400 Original-Received: from IMPmailhost5.adm.correo ([10.20.102.126]) by IMPaqm1.telefonica.net with bizsmtp id tmLA1e00Q2jdgqJ01mgbVu; Fri, 13 Aug 2010 12:40:35 +0200 Original-Received: from ceviche.home ([88.7.8.175]) by IMPmailhost5.adm.correo with BIZ IMP id tmgZ1e00H3mb5G81lmgaex; Fri, 13 Aug 2010 12:40:35 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id C1FBB660F0; Fri, 13 Aug 2010 12:40:33 +0200 (CEST) In-Reply-To: (Kenichi Handa's message of "Fri, 13 Aug 2010 15:18:03 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 13 Aug 2010 06:40: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:39459 Archived-At: >>>> 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". It's the same kind of level as the handling of the `intangible' property or of the various motion-hooks and those are notoriously problematic since they tend to break unrelated code which expects things like goto-char to have very few side-effects. Grep for inhibit-point-motion-hooks to have an idea of the problem. I'm sure we could make it work. But it's just a bad idea to go there. Doing it at the post-command-hook (aka command_loop_1) level is a much better alternative, although it suffers from several other problems. I.e. instead of breaking other code, it suffers from a lack of reliability because this hook has to handle many different cases, and sometimes it's not run at the time we need it (e.g. process filters, queries via read-event, ...). > I was wordering how "S-right" (and S-C-f, etc) are implemented. Pretty ugly. > 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. Important nitpick: it doesn't set it to "forward-char" but to "the command bound to the unshifted key" (i.e. same as it has always done, the only change for that S-C-f feature was to record the fact that the shift modifier had to be stripped to find the command). > 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. The x-set-selection thingy for shift-selection should ideally be performed at the "same place" as the handle-shift-selection. But of course, if/since we do the x-set-selection for any active region (i.e. it's not specific to shift-selection), it makes sense to do it elsewhere. > 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. Yes, it's generally "OK" to do things in post-command-hook (aka command_loop_1), but it's brittle. > 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. I haven't seen any report indicating that users really get confused by that. But I'm not opposed to eliminating this confusion. I just really don't want to see it implemented in set_point_both, and I'm not excited to seeing it in command_loop_1 either. Stefan