how to test whether region is active during a mouse event?

how to test whether region is active during a mouse event?

[Drew Adams]

Suppose the region is active (I'm using transient-mark mode), and I click
mouse-1.

When I look at the events generated by the mouse-button click action, and
whether the region is active for each of those events, I see three events for a
single button click (press + release):

 down,  and the region is active
 down,  and the region is not active
 click, and the region is not active

I want to be able to check whether the region is active during the overall
button-click action. I tried (separately) checking for a `down' event and a
`click' event.

The code is on `post-command-hook'. I want it to check each event and react only
to mouse clicks. And I want it to react differently, depending on whether the
region is active at the time the button is pressed.

If I check only `click' events, I can never see the region as active, because a
previous `down' event inactivates the region.

If I check `down' events instead, the first `down' is treated fine, but the
second `down' is then treated, and for that event the region is inactive. (And
the effect of my code is such that treatment of the second `down' wipes out the
effect of treating the first `down'.)

Questions:

1. Is it normal that there are two `down' events for a simple mouse-button click
action? I assume so, since this is the case since at least Emacs 20. (I'm still
curious as to why.)

2. Given this state of affairs, how can I do what I want: have the code do
something different if the mouse is clicked with or without the region being
active?

The code in question is on `post-command-hook'. It checks whether the region is
active, and then it checks for the mouse event:

(and (string-match "mouse" (format "%S" (event-basic-type last-command-event)))
     (memq 'click (event-modifiers last-command-event)))

Changing `click' to `down' here doesn't help, as explained above: That works for
the first `down' event, but the second `down' event then sees no active region.

Thanks for explanations and suggestions.

RE: how to test whether region is active during a mouse event?

[Drew Adams]

P.S. I suppose I could assume the down, down, click scenario and record the
region info for only the first down. IOW, I could save some state. But I'm
hoping for something a bit cleaner and simpler.

Also, I had the impression (not sure, but I think I saw this when testing) that
if the button-click is in a different frame from the one that had the focus,
then a `switch-frame' event replaces the first `down'. If that kind of thing
happens, then I can't assume a down, down, click event sequence.

Re: how to test whether region is active during a mouse event?

[David De La Harpe Golden]

Drew Adams wrote:


> 1. Is it normal that there are two `down' events for a simple mouse-button click
> action? I assume so, since this is the case since at least Emacs 20. (I'm still
> curious as to why.)
>

Are you defining the active region with the keyboard or mouse?  Do
you see two down events even when you've, say, used shift-arrowkeys
to define the active region then mouse click? (no)

See, you don't see the old down event on the post-command-hook until the 
the whole extended "mouse gesture" started by the old event is 
considered a completed command, so you appear to get two down events in 
rapid succession, at least if you were going by what you see in
a post-command-hook

i.e.

down...drag...up......down..up....
                 ^ not a finished command1, possibly counterintuitively
                       ^finished command1

You can easily see this behaviour by turning on hl-line mode
and selecting a region with the mouse - note the hl-line position
(a post command hook) isn't updated until you do something
else after the mouse-based region selection.


> The code in question is on `post-command-hook'. It checks whether the region is
> active, and then it checks for the mouse event:
> 

It may be better to do it somewhere else, at least in part, and yes, you 
may have to save the value depending on what it is you really want to do 
with it:

One possibility might be the deactivate-mark called before the new 
active region is defined by the new mouse-drag-track*.

So a deactivate-mark hook will capture the previous region on each new 
mouse down (try putting the same thing on post-command-hook and note the 
difference in delivery time)

(defun dtest ()
   (message (format "event(%s:%s) region(activep: %s, contents: '%s')"
		   (event-basic-type last-command-event)
		   (event-modifiers last-command-event)
		   (region-active-p)
		   (buffer-substring (region-beginning) (region-end)))))

(add-hook 'deactivate-mark-hook 'dtest)
; (remove-hook 'deactivate-mark-hook 'dtest)



* The call was actually reordered recently, but that move only means you 
get the correct region during the relevant mark deactivation rather than 
a wierd mix of the old mark to the new point i.e. it's a bugfix (but 
note that in turn means code depending on it will only work on CVS HEAD 
at present).

RE: how to test whether region is active during a mouse event?

[Drew Adams]

> Are you defining the active region with the keyboard or mouse?

The mouse - that's what I was testing with.

> Do you see two down events even when you've, say, used
> shift-arrowkeys to define the active region then mouse click? (no)

No. Likewise, if I use C-x C-x to activate the region. I see only one `down'
followed by a `click'.

Thanks. I didn't think to try that. Since I was testing mouse stuff, it was
simpler to just use the mouse to define the region.

> See, you don't see the old down event on the post-command-hook
> until the the whole extended "mouse gesture" started by the old
> event is considered a completed command, so you appear to get
> two down events in rapid succession, at least if you were going
> by what you see in a post-command-hook i.e.
> down...drag...up......down..up....
>                  ^ not a finished command1
>                        ^finished command1
> 
> You can easily see this behaviour by turning on hl-line mode
> and selecting a region with the mouse - note the hl-line position
> (a post command hook) isn't updated until you do something
> else after the mouse-based region selection.

Got it. Thanks.
 
> > The code in question is on `post-command-hook'. It checks 
> > whether the region is active, and then it checks for the mouse event:
> 
> It may be better to do it somewhere else, at least in part, 
> and yes, you may have to save the value depending on what it
> is you really want to do with it:
> 
> One possibility might be the deactivate-mark called before the new 
> active region is defined by the new mouse-drag-track*.
> 
> So a deactivate-mark hook will capture the previous region on 
> each new mouse down (try putting the same thing on post-command-hook 
> and note the difference in delivery time)
> 
> (defun dtest ()
>    (message (format "event(%s:%s) region(activep: %s, contents: '%s')"
> 		   (event-basic-type last-command-event)
> 		   (event-modifiers last-command-event)
> 		   (region-active-p)
> 		   (buffer-substring (region-beginning) (region-end)))))
> 
> (add-hook 'deactivate-mark-hook 'dtest)
> ; (remove-hook 'deactivate-mark-hook 'dtest)

Very good info, thanks. I didn't know there was a `deactivate-mark-hook'. I see
that it is new for Emacs 23.

Yes, what you suggest sounds good. I'm thinking over my original intention,
though, and I think I might not bother with the specificity wrt region
activeness after all.

But this is very good to know, whether I eventually use it here or elsewhere.

> * The call was actually reordered recently, but that move 
> only means you get the correct region during the relevant mark
> deactivation rather than a wierd mix of the old mark to the
> new point i.e. it's a bugfix (but note that in turn means code
> depending on it will only work on CVS HEAD at present).

Also good to know, I guess. What was the bug (in practical, use-case terms) that
this is intended to fix?

Thx - clear & complete explanation for what I asked.

Re: how to test whether region is active during a mouse event?

[David De La Harpe Golden]

Drew Adams wrote:


> Also good to know, I guess. What was the bug (in practical, use-case terms) that
> this is intended to fix?

select-active-regions was winding up setting incorrect selections in 
some mouse interactions like the ones you were doing.   It "snapshots" 
the last active region's contents when the mark deactivates so that it 
can persist as-is after the mark is deactivated.  Without the 
reordering, it was getting the wrong string sometimes but not always (in 
a pattern that of course retrospectively makes sense, but at the time, 
man...)

RE: how to test whether region is active during a mouse event?

[Drew Adams]

> > Also good to know, I guess. What was the bug (in practical, 
> > use-case terms) that this is intended to fix?
> 
> select-active-regions was winding up setting incorrect selections in 
> some mouse interactions like the ones you were doing.   It 
> "snapshots" the last active region's contents when the mark
> deactivates so that it can persist as-is after the mark is
> deactivated.  Without the reordering, it was getting the wrong
> string sometimes but not always (in a pattern that of course
> retrospectively makes sense, but at the time, man...)

OK, thanks for the explanation, David.


FWIW -

I never heard of `select-active-regions'. That option is not documented in the
Emacs manual or the Elisp manual. And the doc string does not, I'm afraid, help
me understand what it is for or what it does.

Doc string:
"If non-nil, an active region automatically becomes the window selection."

I have no idea what the "window-selection" is. And that term is not even used
anywhere else in the same file that defines it (simple.el). Is it
described/defined anywhere?

Also, user option `select-active-regions' is not used anywhere in the Lisp code,
except for a single occurrence in the definition of function `set-mark'. And
although the option modifies the behavior of `set-mark', it is not mentioned in
the doc (e.g. doc string) for `set-mark'.

To me, this lack of explanation/description is a doc bug, but if you like, take
it as a friendly suggestion:

This is a user option. If you really expect users to understand and use it, then
a little more guidance would help. As it is, (a) I haven't a clue, and (b) I
never would have heard of this if you hadn't referred to it, in passing, in the
context of a bug fix.

The only way to understand what this does is to grep the source code and
discover that it serves as a guard, to prevent (if nil) setting the X-Window
selection. At least that much should be said. If you say "X-Window selection",
at least a user will have something to look up, if it's not clear. "window
selection" is much less helpful.

HTH.

Re: how to test whether region is active during a mouse event?

[David De La Harpe Golden]

Drew Adams wrote:

> FWIW -
> 
> I never heard of `select-active-regions'. 

It's actually been discussed quite a bit on-list*, though in bursts 
spread over the past couple of years. Its behaviour until recently and 
in the 23.1 branch was flawed.  The various required fixes were a bit 
too involved for the release and are only in trunk, so it was 
intentionally removed (or at least de-documented) from 23.1 just a bit 
before the release [1].

* e.g. Eli Zaretskii just recently raised a couple of issues with the 
initial fixed (see bug #973) implementation now in trunk, I am presently 
attempting to bring up emacs under wine to look more closely at them -
basically (a) making it optionally affect clipboard and (b) making
it a bit less platform-specific in implementation.

> Doc string:
> "If non-nil, an active region automatically becomes the window selection."
> 
> I have no idea what the "window-selection" is. And that term is not even used
> anywhere else in the same file that defines it (simple.el). Is it
> described/defined anywhere?

It's pretty close to X11 terminology, though I would have said "window 
system primary selection". Primary? X11 has multiple 
vaguely-clipboard-like entities called "selections", a perennial source 
of confusion.  select-active-regions in conjunction with a few other 
customizations helps emacs optionally largely match one particular 
convention for their use.

primary and select-active-regions are mentioned in the post-23.1 manual, 
at Frames > Cut and Paste > Cut/Paste Other App

 > This is a user option. If you really expect users to understand and
 > use it,

Only post-23.1...


[1]
http://cvs.savannah.gnu.org/viewvc/emacs/etc/NEWS?view=log&root=emacs&pathrev=EMACS_23_1#rev1.2029.2.3

Re: how to test whether region is active during a mouse event?

[Stefan Monnier]

> Suppose the region is active (I'm using transient-mark mode), and I click
> mouse-1.

> When I look at the events generated by the mouse-button click action,
> and whether the region is active for each of those events, I see three
> events for a single button click (press + release):

>  down,  and the region is active
>  down,  and the region is not active
>  click, and the region is not active

The second down event looks odd but guess it's the result of a (push foo
unread-command-events) somewhere in the processing of the first.

> I want to be able to check whether the region is active during the overall
> button-click action.

I don't know what that means.  Could you describe it more precisely?


        Stefan

RE: how to test whether region is active during a mouse event?

[Drew Adams]

> > I want to be able to check whether the region is active 
> > during the overall button-click action.
> 
> I don't know what that means.  Could you describe it more precisely?

Please see the rest of the thread. See in particular David DLH's first post, on
2009-08-02.

Summary: David DLH explained the cause of the problem. He suggested a possible
workaround. I decided anyway to abandon my attempt to distinguish whether the
region is active when the mouse is clicked (either `down' or `click' modifier -
both had problems).