GNU bug report logs - #17562
24.4.50; REGRESSION: mouse double-click on `(` does not select whole Lisp sexp

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17562 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: bug#17562: 24.4.50; REGRESSION: mouse double-click on `(` does not select whole Lisp sexp
Date: Tue, 27 May 2014 02:55:04 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> > Visit dired.el. Double-click on the opening paren of
> > (defun dired-get-filename ...
> > Only part of the defun is selected.
>
> Hmm... I can't reproduce it here (using "emacs -Q"):
> - after opening dired.el I first have to search for "defun
> dired-get-filename"
>   because it's not immediately visible.
> - once it's in sight, if I double-click on it, the whole expression is
>   selected&highlighted, point is moved to right after the matching close
>   paren, and as a consequence the window is redrawn to show the end of
>   the expression (since the beginning is now outside of the window).
>
> I never use this feature, but I see the exact same behavior in
> Emacs-24.3, so I assume it's the way it's always worked.
>
> Can you reproduce the problem with "emacs -Q"?

Yes.  There is no misunderstanding, you obviously don't see what we
see.  Are you sure you tried with trunk, and not emacs-24?

Here's what I found out in the meantime:

In contrast to before the above commit, the second click now leads to a call
to `mouse-set-region'.  I tried to debug-on-entry `mouse-set-region' in
both emacs -Q and tried our recipe:

 - Without your commit, the command is not run (no debugger)
 
 - With your commit, the debugger pops up.  When the debugger pops up,
   the window already has been scrolled, and point is indeed at the end
   of the sexp.  After `mouse-set-region' has finished, point has been
   replaced according to the position under the mouse (after scrolling).

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.


Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.