[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17562: 24.4.50; REGRESSION: mouse double-click on `(` does not selec
bug#17562: 24.4.50; REGRESSION: mouse double-click on `(` does not select whole Lisp sexp
Tue, 27 May 2014 01:08:30 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
> In general, in current trunk, when window scrolling happens, point is
> now always positioned in the line under the mouse, instead of after the
> sexp. Seems like something happens similar to what is described in the
> old code:
> ;; Don't run the up-event handler if the window
> ;; start changed in a redisplay after the
> ;; mouse-set-point for the down-mouse event at
> ;; the beginning of this function. When the
> ;; window start has changed, the up-mouse event
> ;; contains a different position due to the new
> ;; window contents, and point is set again.
Indeed, it's something along these lines, although the above code is not
reached anyway in this kind of "double click on a paren" situation.
The problem is that Emacs generates a drag event even though there's not
been a drag per-se, and the end-posn of the drag is based on the "after
scroll" display, whereas the user usually hasn't had the time to really
see this display before releasing his mouse button.
The old code used a hack to work around the problem, and I installed
another hack that does something morally very similar, although it gets
there in a fairly different way.
In both the old and the new code you can still get the undesired
behavior if you move your mouse slightly between the second down-mouse
and the second up-mouse.