bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#66655: 29.1; Clicking buttons sometimes doesn't work


From: Stefan Monnier
Subject: bug#66655: 29.1; Clicking buttons sometimes doesn't work
Date: Thu, 26 Oct 2023 10:05:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> Because as soon as `note_mouse_highlight` receives information that the
>> mouse is outside of the fuzz, the var is set to `false` [ And it's only
>> set to true when we get the mouse-down event ].
>
> I don't think I understand this explanation.  (Did you mean "true"
> instead of "false"?)

Yes, I reversed them (and I made a similar mistake in one of the
comments in the patch.  I'm having some kind of "polarity issue",
apparently, sorry 'bout that).

> You started by saying that your code detects mouse movement, and I
> asked how does it detect it.  AFAIR, Emacs doesn't receive
> mouse-motion events unless we turn on track-mouse, which we usually
> avoid doing.

It does receive them (it uses them for `mouse-face` highlighting).
`track-mouse` only controls whether those C-level events get turned
into ELisp-level events.

>> > Yes: we can be at the same buffer position, but a different window.
>> Right, but what's the problem with that?
>
> You could have redisplay change the windows under your feet, such that
> the screen coordinates are the same, the buffer position is the same,
> but the window is not the same.  That test wants to emit a drag event
> in such a case.  That is my understanding of the test.

No, the code does:

                if (mouse_has_moved
                    || (!EQ (Fcar (Fcdr (start_pos)),
                             Fcar (Fcdr (position)))
                         && EQ (Fcar (start_pos),
                                Fcar (position)))))

so the last `EQ` *prevents* emitting a drag event when the window has
changed (but only when the mouse's start and end screen position are the
same).

>> I think my code is immune to this problem since with it we only ever
>> generate a drag event if the mouse actually moved.  Which leads to
>> a further simplification of the code, see patch below.
> I still don't understand the implication of the mouse_has_moved part.

The implication, AFAICT is that with my current code you can't easily
drag over a distance less than fuzz:

     down-mouse-1
     ...move a tiny bit to the next char-cell...
     up-mouse-1

will turn into a click.

But indeed, that's what the fuzz is about because the above "move" could
have been accidental the mere result of pushing the mouse button (what
I'd call "click with noise").

Not sure how to distinguish the above drag from a "click with noise".
Maybe we should take *time* into account?


        Stefan






reply via email to

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