From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: Mouse cut moves point Date: Thu, 3 Jan 2013 18:25:51 -0700 Message-ID: <20130104012551.GA20410@hysteria.proulx.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1357262765 30672 80.91.229.3 (4 Jan 2013 01:26:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2013 01:26:05 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 04 02:26:21 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tqw38-0000Kn-Kt for geh-help-gnu-emacs@m.gmane.org; Fri, 04 Jan 2013 02:26:18 +0100 Original-Received: from localhost ([::1]:36088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tqw2s-0004Qh-MQ for geh-help-gnu-emacs@m.gmane.org; Thu, 03 Jan 2013 20:26:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tqw2l-0004QP-19 for help-gnu-emacs@gnu.org; Thu, 03 Jan 2013 20:25:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tqw2j-00009k-I3 for help-gnu-emacs@gnu.org; Thu, 03 Jan 2013 20:25:54 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:40060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tqw2j-00009e-5i for help-gnu-emacs@gnu.org; Thu, 03 Jan 2013 20:25:53 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 1F41C21254 for ; Thu, 3 Jan 2013 18:25:52 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id A6E1C2DCCA; Thu, 3 Jan 2013 18:25:51 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:88429 Archived-At: Barry Margolin wrote: > Bob Proulx wrote: > > In emacs running as a graphics window the act of cutting text moves > > the point. Typing in text and then using the mouse to cut and paste > > means also needing to tediously move the point back to where I was > > typing (before the cut action) so that I can paste it. > > > > Is there a way to configure emacs under X so that cutting text with a > > mouse drag does not move the point? > > Emacs's model of marking text is that the region is the area between the > mark and point. So it's not possible to mark a region without setting > point to one end of it. Yes. That is the way it has always been. The region between the mark and the point. But then along comes X Windows and a lot of decisions and time and decisions and implementation. Just because one person made that implementation decision to move the point when dragging the mouse doesn't mean that it was the only possible one to make. If I had been programming the mouse behavior I am sure I would have made different choices. And then it would be someone else complaining about my behavior choices and asking about how to customize them differently! Looking through mouse.el now and I see various things. Left mouse-1 is bound to mouse-set-point, which is fine. drag-mouse-1 is bound to mouse-set-region, which is also fine but inconvenient. It is programmable. I just want a different behavior programmed for this action! Hoping that someone has already solved this problem! :-) But if you have never wanted it then it won't have been an itch that you ever needed to have scratched. So perhaps unlikely. I asked anyway. I think maybe if I create a new function and save-excursion and have it call mouse-set-region in order to update the kill-ring and then bind this new function to drag-mouse-1 instead then after a mouse drag cut to set the kill-ring I could have it return to the previous location of the point. > But isn't this also how most GUI text editors and word processors work? > When you swipe an area of text the insertion point disappears. But if > you cut and then start typing, you'll see that it has moved to where the > marked text was. Probably. But what other GUI text editors do is not really germane to the question of improving the emacs GUI behavior. Other editors are often modal but that does not mean that we should make emacs modal just to be like other editors. The difference is what makes emacs attractive to emacs users. And the reverse for the others. It is okay to have different behaviors for different people. Basically the behavior I desire is the same behavior that naturally occurs when running emacs in text mode in a text terminal such as an xterm. In a text terminal cutting text interacts with the terminal, not emacs, and doesn't move the emacs point. Paste interacts with the terminal again and emacs just receives text as input the same as if I had typed it in from the keyboard. The text is pasted at point which is where I was typing and cutting didn't move it from there. It is the perfect behavior for me and I would like to have that even when using emacs with a graphics display where it knows about the mouse. Otherwise this is a case where emacs in X is less nice than emacs in a text terminal. For me anyway. Bob