bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

Hi,

I'm not entirely sure whether this is a bug or a feature, but selecting 
a region with a combination of keyboard and mouse doesn't work any 
longer in Emacs 24, at least not in a plain emacs -Q session. Marking 
the start of a region with C-SPC and then using a simple mouse click to 
mark the end doesn't work anymore, because clicking anywhere seems to 
set the mark now. My muscle memory, trained over decades by Emacs 23 and 
its predecessors, doesn't like this change. I keep M-w'ing and C-w'ing 
empty regions :-(. What's also a bit annoying IMHO is that fact, that 
the Cut and Copy buttons in the tool-bar flash everytime I click 
somewhere to position the cursor. I just notice this now, because I 
don't have a tool-bar in my usual customization.

Is there a customization option that I've overlooked which prevents 
<down-mouse-1> (or is it <mouse-1>?) from setting the mark?
I've also looked over the "** Selection changes" part of etc/NEWS, but 
didn't find anything related to this particular effect.

Kind regards,
Tobias

---

In GNU Emacs 24.0.97.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
  of 2012-05-25 on pen-bld-274apcl
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
Configured using:
  `configure '--prefix=...''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: POSIX
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: de_DE.utf8
   value of $LANG: en_US.utf8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<up> <up> <up> <up> <right> <right> <right> <right>
<right> <right> <right> <right> <right> C-SPC <down-mouse-1>
<mouse-1> C-w <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Chong Yidong]

Tobias Bading <tbading@web.de> writes:

> Marking the start of a region with C-SPC and then using a simple mouse
> click to mark the end doesn't work anymore, because clicking anywhere
> seems to set the mark now.  My muscle memory, trained over decades by
> Emacs 23 and its predecessors, doesn't like this change.
>
> Is there a customization option that I've overlooked which prevents
> <down-mouse-1> (or is it <mouse-1>?) from setting the mark?

mouse-1 does not set the mark, but it does deactivate the mark if the
mark was active.  But that is the case in both Emacs 23 and Emacs 24, so
I don't know what you're talking about.

To extend the region, the usual Emacs command is mouse-3 (right click),
which works in both Emacs 23 and Emacs 24.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

On 30.05.2012, at 16:15, Chong Yidong wrote:
> Tobias Bading <tbading@web.de> writes:
> 
>> Marking the start of a region with C-SPC and then using a simple mouse
>> click to mark the end doesn't work anymore, because clicking anywhere
>> seems to set the mark now.  My muscle memory, trained over decades by
>> Emacs 23 and its predecessors, doesn't like this change.
>> 
>> Is there a customization option that I've overlooked which prevents
>> <down-mouse-1> (or is it <mouse-1>?) from setting the mark?
> 
> mouse-1 does not set the mark, but it does deactivate the mark if the
> mark was active.  But that is the case in both Emacs 23 and Emacs 24, so
> I don't know what you're talking about.

Umm... emacs -Q:
C-h v mark-ring RET shows that mark-ring is initially nil.
Now click <n> times with the left mouse button somewhere in the *scratch* buffer.
Now mark-ring contains <n-1> elements.

Am I missing or misinterpreting something here?
C-SPC, left mouse click somewhere, then C-w doesn't kill anything. In Emacs 23, it did.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> > mouse-1 does not set the mark, but it does deactivate the 
> > mark if the mark was active.
> 
> Umm... emacs -Q:
> C-h v mark-ring RET shows that mark-ring is initially nil.
> Now click <n> times with the left mouse button somewhere in 
> the *scratch* buffer. Now mark-ring contains <n-1> elements.
> 
> Am I missing or misinterpreting something here?

No, you are correct.  C-h k, then click mouse-1.  You'll see that `down-mouse-1'
is bound to `mouse-drag-region', but `mouse-1' is bound to `mouse-set-point',
which sets point to the click position.

> C-SPC, left mouse click somewhere, then C-w doesn't kill 
> anything. In Emacs 23, it did.

You are correct about that also.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Chong Yidong]

Tobias Bading <tbading@web.de> writes:

> Umm... emacs -Q:
> C-h v mark-ring RET shows that mark-ring is initially nil.
> Now click <n> times with the left mouse button somewhere in the
> *scratch* buffer.
> Now mark-ring contains <n-1> elements.
>
> Am I missing or misinterpreting something here?  C-SPC, left mouse
> click somewhere, then C-w doesn't kill anything. In Emacs 23, it did.

OK, now I see what you mean.

The old mouse dragging code had a special behavior to pop the mark if
you did not move the mouse much after the down event, to avoid setting
the mark (this did not work reliably; if you move the mouse a little bit
between the down and up events, the mark gets set anyway).  I'll see if
there is a way to get this to work with the new code, but it won't be
for the 24.1 release.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> OK, now I see what you mean.
> 
> The old mouse dragging code had a special behavior to pop the mark if
> you did not move the mouse much after the down event, to avoid setting
> the mark (this did not work reliably; if you move the mouse a little bit
> between the down and up events, the mark gets set anyway).  
> I'll see if there is a way to get this to work with the new code, but it
> won't be for the 24.1 release.

Why not?  The "old" behavior was the behavior forever, and for a reason.

Why release with the regression?  What's the hurry?

Why not restore the old code, and move the "new" to 24.2 and fix it there,
taking as much time as you like to get it right?

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

On 30.05.2012, at 18:42, Drew Adams wrote:
>> OK, now I see what you mean.
>> 
>> The old mouse dragging code had a special behavior to pop the mark if
>> you did not move the mouse much after the down event, to avoid setting
>> the mark (this did not work reliably; if you move the mouse a little bit
>> between the down and up events, the mark gets set anyway).  
>> I'll see if there is a way to get this to work with the new code, but it
>> won't be for the 24.1 release.
> 
> Why not?  The "old" behavior was the behavior forever, and for a reason.
> 
> Why release with the regression?  What's the hurry?
> 
> Why not restore the old code, and move the "new" to 24.2 and fix it there,
> taking as much time as you like to get it right?

The bug in Emacs 23 caused by a slight mouse movement between mouse down and up events that Chong described is quite bad IMHO. Probably worse than a mouse click setting the mark every time. Please don't put that bug back in :-).

Tobias

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> The bug in Emacs 23 caused by a slight mouse movement between 
> mouse down and up events that Chong described is quite bad 
> IMHO. Probably worse than a mouse click setting the mark 
> every time. Please don't put that bug back in :-).

Now it's my turn to say I don't understand.

Whether in Emacs 22, 23, or 24, if you move the mouse more than a character
width between down and up then you end up selecting the text you dragged over,
even if it is only one char - and thus highlighting it.  If you then hit `C-w',
the selected text is killed.  C'est normal.

You can _see_ the text to be killed.  That's the point of mouse-selection
highlighting (and the point behind transient-mark-mode highlighting).  If you
don't want to kill the text that you see highlighted, then don't kill it.

I don't understand the problem that the change is designed to fix.  You say that
you hit C-SPC, then you clicked mouse-1 elsewhere but you mistakenly dragged a
bit between button down and up.  OK.  It should have been clear with the
highlighting that the text to be killed did not extend from your C-SPC.  Where
was the mystery?

Sounds like a case of if-it-hurts-don't-do-it.

FWIW, I don't think I have ever mistakenly dragged the mouse slightly between
down and up.  Maybe I've been lucky.

But if some people have that problem then the solution is to do what we do
generally for GUIs (e.g. for double-clicking speed): let users customize the
tolerance for such dragging.  Setting your tolerance greater than one char (e.g.
1.4 chars) would probably take care of your problem.  Of course, if you set it
too high (e.g. 1.6 chars) then you cannot then select a single char with the
mouse...  

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

On 30.05.2012, at 19:18, Drew Adams wrote:
>> The bug in Emacs 23 caused by a slight mouse movement between 
>> mouse down and up events that Chong described is quite bad 
>> IMHO. Probably worse than a mouse click setting the mark 
>> every time. Please don't put that bug back in :-).
> 
> Now it's my turn to say I don't understand.
> 
> Whether in Emacs 22, 23, or 24, if you move the mouse more than a character
> width between down and up then you end up selecting the text you dragged over,
> even if it is only one char - and thus highlighting it.  If you then hit `C-w',
> the selected text is killed.  C'est normal.
> 
> You can _see_ the text to be killed.  That's the point of mouse-selection
> highlighting (and the point behind transient-mark-mode highlighting).  If you
> don't want to kill the text that you see highlighted, then don't kill it.
> 
> I don't understand the problem that the change is designed to fix.  You say that
> you hit C-SPC, then you clicked mouse-1 elsewhere but you mistakenly dragged a
> bit between button down and up.  OK.  It should have been clear with the
> highlighting that the text to be killed did not extend from your C-SPC.  Where
> was the mystery?
> 
> Sounds like a case of if-it-hurts-don't-do-it.

Wish it was that easy. I think Chong meant a mouse movement by just a few pixels, not characters. At least that would explain perfectly my am-I-to-stupid-to-use-a-mouse-or-what moments. I obviously moved the mouse a pixel or two while clicking, resulting in a mark being set at point. C-w or M-w after that kills or copies an empty region. That's exactly what I managed to do every once in a while in Emacs 23. At least Emacs 24 is consistent, it never works ;-).

> FWIW, I don't think I have ever mistakenly dragged the mouse slightly between
> down and up.  Maybe I've been lucky.

Yup, checking my medication might solve my problem, too. :-D

Tobias

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> Wish it was that easy. I think Chong meant a mouse movement 
> by just a few pixels, not characters. At least that would 
> explain perfectly my am-I-to-stupid-to-use-a-mouse-or-what 
> moments. I obviously moved the mouse a pixel or two while 
> clicking, resulting in a mark being set at point. C-w or M-w 
> after that kills or copies an empty region. That's exactly 
> what I managed to do every once in a while in Emacs 23. At 
> least Emacs 24 is consistent, it never works ;-).

Yidong said, "if you move the mouse a little bit between the down and up events,
the mark gets set anyway".  So it sounds like that "little-bit" setting, if only
a pixel or two, was too small.  I would have guessed (incorrectly) that it would
have been at least half of a char-width.

But as I said, the best thing in a case like this, where different users would
anyway want/need different tolerances, would be to provide a user setting
(option) for the slop movement between down and up.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

On 30.05.2012, at 19:41, Drew Adams wrote:
> Yidong said, "if you move the mouse a little bit between the down and up events,
> the mark gets set anyway".  So it sounds like that "little-bit" setting, if only
> a pixel or two, was too small.  I would have guessed (incorrectly) that it would
> have been at least half of a char-width.
> 
> But as I said, the best thing in a case like this, where different users would
> anyway want/need different tolerances, would be to provide a user setting
> (option) for the slop movement between down and up.

Agreed, some threshold value (probably in pixels) to distinguish between a click and a drag would be nice.

Although, isn't this part of the job of a window system? Something like: When a mouse button is pressed, only start sending mouse-move events after the mouse has travelled at least a small distance? Otherwise every click on an icon with a non-100% steady hand would be interpreted as a request to move the icon. Oh my, GUI stuff is complicated ;-).

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> Although, isn't this part of the job of a window system? 
> Something like: When a mouse button is pressed, only start 
> sending mouse-move events after the mouse has travelled at 
> least a small distance? Otherwise every click on an icon with 
> a non-100% steady hand would be interpreted as a request to 
> move the icon. Oh my, GUI stuff is complicated ;-).

The window mgr doesn't know what Emacs defines as a drag, and it has no notion
of setting point.  Emacs should define the behavior for itself.  The Emacs mouse
is a bit special all 'round - much of how it behaves is particular to Emacs.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

> The window mgr doesn't know what Emacs defines as a drag, and it has no notion
> of setting point.  Emacs should define the behavior for itself.  The Emacs mouse
> is a bit special all 'round - much of how it behaves is particular to Emacs.

Sure, but from a user's point of view, shouldn't all applications running under the same window system have the same understanding of a "drag gesture"? I just took a peek into the Apple Cocoa docs, and Apple defines a mouseDragged event. So on Mac OS, it seems that it is not the application's job to determine whether a click starts a drag or is just a click, the window system does that job for the application. Makes sense to me. However, my experience with Mac OS GUI programming is rather limited and the last time I wrote X11 code is ages ago, so there are probably lots of people in here who are better qualified than me to figure out the best way to deal with this problem.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Drew Adams]

> Sure, but from a user's point of view, shouldn't all 
> applications running under the same window system have the 
> same understanding of a "drag gesture"?

Not necessarily, if "drag gesture" and "drag" mean different things for
different applications.

But yes, I imagine that there should be such a user setting at the window mgr
level, possibly with overriding by an app's user settings.

> I just took a peek into the Apple Cocoa docs, and Apple
> defines a mouseDragged event. So on Mac OS, it seems that it
> is not the application's job

Not the application's job is one thing - I'd agree.

That doesn't mean an application shouldn't or couldn't have its own, overriding
notion of a drag event.  If an app can have its own notion of a zimphlot event,
then it can call it "my-drag"...

> to determine whether a click starts a drag 
> or is just a click, the window system does that job for the 
> application.

By default, yes.  But it's just like the click itself, which Emacs defines to
some extent.  Not that the app _has_ to, but it _can_.

Re: bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[dove.young]

On May 31, 1:26 am, Tobias Bading <tbad...@web.de> wrote:
> On 30.05.2012, at 19:18, Drew Adams wrote:
>
>
>
>
>
>
>
>
>
> >> The bug in Emacs 23 caused by a slight mouse movement between
> >> mouse down and up events that Chong described is quite bad
> >> IMHO. Probably worse than a mouse click setting the mark
> >> every time. Please don't put that bug back in :-).
>
> > Now it's my turn to say I don't understand.
>
> > Whether in Emacs 22, 23, or 24, if you move the mouse more than a character
> > width between down and up then you end up selecting the text you dragged over,
> > even if it is only one char - and thus highlighting it.  If you then hit `C-w',
> > the selected text is killed.  C'est normal.
>
> > You can _see_ the text to be killed.  That's the point of mouse-selection
> > highlighting (and the point behind transient-mark-mode highlighting).  If you
> > don't want to kill the text that you see highlighted, then don't kill it.
>
> > I don't understand the problem that the change is designed to fix.  You say that
> > you hit C-SPC, then you clicked mouse-1 elsewhere but you mistakenly dragged a
> > bit between button down and up.  OK.  It should have been clear with the
> > highlighting that the text to be killed did not extend from your C-SPC.  Where
> > was the mystery?
>
> > Sounds like a case of if-it-hurts-don't-do-it.
>
> Wish it was that easy. I think Chong meant a mouse movement by just a few pixels, not characters. At least that would explain perfectly my am-I-to-stupid-to-use-a-mouse-or-what moments. I obviously moved the mouse a pixel or two while clicking, resulting in a mark being set at point. C-w or M-w after that kills or copies an empty region. That's exactly what I managed to do every once in a while in Emacs 23. At least Emacs 24 is consistent, it never works ;-).
>
> > FWIW, I don't think I have ever mistakenly dragged the mouse slightly between
> > down and up.  Maybe I've been lucky.
>
> Yup, checking my medication might solve my problem, too. :-D
>
> Tobias

So is there any possible way to just click mouse button 1 without
changing marks? I have many functions rely on the mark positions and I
still need them in my daily work. Thanks.

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Eli Zaretskii]

> From: "dove.young" <dove.young@gmail.com>
> Date: Sun, 24 Jun 2012 00:51:38 -0700 (PDT)
> 
> So is there any possible way to just click mouse button 1 without
> changing marks? I have many functions rely on the mark positions and I
> still need them in my daily work. Thanks.

Didn't you read the last message in the bug report, where a fix was
announced and installed in the development sources?

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Tobias Bading]

> The old mouse dragging code had a special behavior to pop the mark if
> you did not move the mouse much after the down event, to avoid setting
> the mark (this did not work reliably; if you move the mouse a little bit
> between the down and up events, the mark gets set anyway).

HURRAY, I'm not losing my mind! Thank you, Chong! A slight mouse movement between the mouse down and up events causing the mark to be set in Emacs 23 finally explains why sometimes I was unable to kill or copy a region with C-SPC at point, mouse click there and then C-w or M-w. That is quite a bad bug in Emacs 23 then to be honest.

Tobias

bug#11588: 24.0.97; Left mouse click setting the mark every time?!??

[Chong Yidong]

Tobias Bading <tbading@web.de> writes:

>> The old mouse dragging code had a special behavior to pop the mark if
>> you did not move the mouse much after the down event, to avoid setting
>> the mark (this did not work reliably; if you move the mouse a little bit
>> between the down and up events, the mark gets set anyway).
>
> HURRAY, I'm not losing my mind! Thank you, Chong! A slight mouse
> movement between the mouse down and up events causing the mark to be
> set in Emacs 23 finally explains why sometimes I was unable to kill or
> copy a region with C-SPC at point, mouse click there and then C-w or
> M-w. That is quite a bad bug in Emacs 23 then to be honest.

I've committed a fix to trunk.  Now clicking and releasing in the same
position, if you do not drag the mouse to any other position, will not
set the mark.