--- Begin Message ---
|
Subject: |
24.4.50; REGRESSION: mouse double-click on `(` does not select whole Lisp sexp |
|
Date: |
Fri, 23 May 2014 10:00:17 -0700 (PDT) |
Regression after Emacs 24.3.
emacs -Q
Visit dired.el. Double-click on the opening paren of
(defun dired-get-filename ...
Only part of the defun is selected. It seems that a defun needs to fit
entirely within the window (i.e., be completely visible) for mouse
selection by double-clicking to work correctly now.
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-05-17 on ODIEONE
Bzr revision: 117119 address@hidden
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#17562: 24.4.50; REGRESSION: mouse double-click on `(` does not select whole Lisp sexp |
|
Date: |
Tue, 27 May 2014 01:08:30 -0400 |
|
User-agent: |
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.
Stefan
--- End Message ---