Re: Mouse cut moves point

Re: Mouse cut moves point

[Barry Margolin]

In article <mailman.16636.1357253037.855.help-gnu-emacs@gnu.org>,
 Bob Proulx <bob@proulx.com> 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?
> 
> This is something that has always been this way.  It has not ever
> changed as far as I know.  But it has always been inconvenient.  I had
> such excellent luck with my last question that I decided it was time
> to ask this related question too. :-)

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.

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.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Mouse cut moves point

[Bob Proulx]

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

Re: Mouse cut moves point

[Bob Proulx]

Bob Proulx wrote:
> 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.

This does 90% of what I want.

(defun mouse-drag-region-no-move-point (start-event)
  "Calls mouse-drag-region but without moving the point."
  (interactive "e")
  (save-excursion (mouse-drag-region start-event)))

(global-set-key [down-mouse-1] 'mouse-drag-region-no-move-point)

Yay!  This is a significant improvement for me.  Working with
double-click for words and tripple-click for lines would be nice but
more complicated.

Bob

Mouse cut moves point

[Bob Proulx]

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?

This is something that has always been this way.  It has not ever
changed as far as I know.  But it has always been inconvenient.  I had
such excellent luck with my last question that I decided it was time
to ask this related question too. :-)

Thanks,
Bob