[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Fix for `use-region-p' problem [was: Elisp test f

From: Drew Adams
Subject: RE: [External] : Re: Fix for `use-region-p' problem [was: Elisp test for whether `mouse-1' is pressed?]
Date: Mon, 8 Nov 2021 18:32:41 +0000

Thanks for replying, Tomas.

> > I got no response to my question of how to tell
> > whether `mouse-1' is still pressed during a click.
> [...]
> I read twice through your text and I'm still trying
> to wrap my head around the gist of it.

Sorry for any confusion or difficulty.

I can't tell if you mean that you had difficulty with
(1) the original post, asking how to tell when mouse-1
is pressed (the text you quoted) or with (2) my last
message (with changed Subject), which is what you
replied to.  Or perhaps you had difficulty with both?

> My feeling (it mitght be totally wrong: I'm trying to expound
> it just in an attempt to debug what's going on) is that you
> are connecting directly two layers which are too far apart: at
> the abstract/model/text end selection and its handling, at the
> concrete/physical/UI end the mouse clicks.

I can't speak to your feeling or the distinction you
describe.  You can select text with the mouse (or
otherwise) - maybe that's one connection.

I have no problem with the abstract behavior of
selection, with or without the mouse.  And I have no
problem with its concrete realization.

The problem I described is only with the implementation
of predicate `use-region-p'.  Its (minor) failing is
only with a corner case: returning true between mouse-1
down and up events during a click action (down & up at
the same place).

When you press mouse-1, drag-tracking is started, so
that if you move the mouse across text, that text gets
selected.  As long as you hold mouse-1 down, tracking
continues (well, unless interrupted by some other event
such as a keyboard key).

Roughly speaking, When you release mouse-1 the selected
text is used for the region, and the region/mark is
left activated.  But if you release mouse-1 at the same
place you pressed it, that release (button-up) event
deactivates the (empty) region.

From a _user_ point of view, when you start to do
something just after a click the region is inactive.
Your action after a click does _not_ act on an empty
active region.  This is all as it should be.

Event `down-mouse-1' (button-down) activates the region,
and event `mouse-1' (button-up) either (1) leaves it
activated, if the positions of down & up differ, or (2)
deactivates it, if those positions are the same.  (See
function `mouse-drag-track' for details.)

My original question was how to tell whether/when the
mouse is tracking.  In Emacs 24 (only) I found it was
sufficient to test whether `echo-keystrokes' is 0 - a
dumb and fragile hack.  I was now looking for a better
test, one that works across Emacs versions.

The better test I came up with, is this:

(and (not (eq 'down-mouse-1 (car-safe last-input-event)))
     (not (mouse-movement-p last-input-event)))

That is, whenever the region is empty (and assuming
the user OK's empty-region indication), if the last
input event wasn't `down-mouse-1' and it wasn't a
mouse movement, then it's OK to show the
active-region indication in the mode-line.

(Not sure why, but apparently if you click mouse-1 on
a different frame then the last event after pressing
mouse-1 is a mouse movement, not `down-mouse-1'.)

That seems to work well in the releases I support for
this so far: Emacs 24-27.  Maybe it too is fragile
and fortuitous, and won't work in Emacs release 42.
(Maybe Emacs should provide a predicate for mouse-1
being pressed and not yet released?)

> In another debugging attempt: could you try to explain
> what you are up to assuming the user has no mouse?

If the user has no mouse, or isn't using it in this
context, there's no change at all.  There's also no
effect on dragging the mouse (e.g. selecting text -
nonempty region).  The behavior to be fixed only
involves a mouse-1 click (down & up at the same place).  

> Now the above sounds as if I was trying to imply that you are
> somehow "wrong". That I am not! I'm just at a loss trying to
> understand what you are trying and even feel it's difficult for
> me adequately expressing my difficulties.

I appreciate your response.  I hope others will also
read what I wrote and speak up.  Let me know what
else I can add, if something's still unclear.

Some more background about my use case, in case it
helps or you're interested.  (The code is small,
in modeline-region.el - see URL below.)

Minor mode `modeline-region-mode' shows, in the
mode-line, whether the region is active (and some
info about its size - various counts etc.).

Standard Emacs commands such as search & replace
are advised when the mode is on, so that the
mode-line indication of the region status makes
clear that the current command is actually acting
on the region, not the buffer.  (The face used is
a bit different, to draw attention to this.)

Non-nil option `mlr-empty-region-flag' means show
the active-region indication in the mode-line even
when the region is empty.  It's non-nil by default,
because being told that you're acting on, or about
to act on, the empty region can save you some bother.

All of this description applies regardless of how
you select text - using the mouse or otherwise.

What was problematic, and the problem I wanted to
fix, was that if you clicked mouse-1 then an empty
region was briefly indicated spuriously.

This happened because as soon as you press mouse-1
the region is activated, even though as soon as
you release mouse-1 it is deactivated.  In this
case you momentarily saw, in the mode-line, an
indication of an activated empty region.  That
momentary display (~ a flash) was a bit bothersome.

I fixed that.  I think the problem is present also
for vanilla Emacs, and the same fix makes sense
for it.  That's what my message now is about: the
problem with `use-region-p' and a proposed fix.

Admittedly, unless you have some similar use case -
continually monitoring and indicating region
activation - you won't notice or care about the
problem.  And yes, if you don't use a mouse then
you also won't care about it.

I think it's worth it for Emacs to fix this corner
case, e.g., have `use-region-p' return nil when
the region is empty if mouse-1 is currently still

Why?  Because you can't use the active region then,
and that's what `use-region-p' is for: saying when
you can use the active region.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]