From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: how to test whether region is active during a mouse event? Date: Sun, 02 Aug 2009 21:31:16 +0100 Message-ID: <4A75F794.103@harpegolden.net> References: <1907CCC7DE424D73AA8FD0E2F798DF49@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249245168 7738 80.91.229.12 (2 Aug 2009 20:32:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Aug 2009 20:32:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 02 22:32:41 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MXhjA-0002r5-O5 for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2009 22:32:40 +0200 Original-Received: from localhost ([127.0.0.1]:54458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXhj8-00045U-Oe for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2009 16:32:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXhiQ-0003si-Cq for emacs-devel@gnu.org; Sun, 02 Aug 2009 16:31:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXhiL-0003r3-O7 for emacs-devel@gnu.org; Sun, 02 Aug 2009 16:31:33 -0400 Original-Received: from [199.232.76.173] (port=45887 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXhiL-0003qx-Il for emacs-devel@gnu.org; Sun, 02 Aug 2009 16:31:29 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:33845) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MXhiL-0004Gg-34 for emacs-devel@gnu.org; Sun, 02 Aug 2009 16:31:29 -0400 Original-Received: from [87.198.47.55] (87-198-47-55.ptr.magnet.ie [87.198.47.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 6F0188275; Sun, 2 Aug 2009 21:31:26 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) In-Reply-To: <1907CCC7DE424D73AA8FD0E2F798DF49@us.oracle.com> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113569 Archived-At: Drew Adams wrote: > 1. Is it normal that there are two `down' events for a simple mouse-button click > action? I assume so, since this is the case since at least Emacs 20. (I'm still > curious as to why.) > Are you defining the active region with the keyboard or mouse? Do you see two down events even when you've, say, used shift-arrowkeys to define the active region then mouse click? (no) See, you don't see the old down event on the post-command-hook until the the whole extended "mouse gesture" started by the old event is considered a completed command, so you appear to get two down events in rapid succession, at least if you were going by what you see in a post-command-hook i.e. down...drag...up......down..up.... ^ not a finished command1, possibly counterintuitively ^finished command1 You can easily see this behaviour by turning on hl-line mode and selecting a region with the mouse - note the hl-line position (a post command hook) isn't updated until you do something else after the mouse-based region selection. > The code in question is on `post-command-hook'. It checks whether the region is > active, and then it checks for the mouse event: > It may be better to do it somewhere else, at least in part, and yes, you may have to save the value depending on what it is you really want to do with it: One possibility might be the deactivate-mark called before the new active region is defined by the new mouse-drag-track*. So a deactivate-mark hook will capture the previous region on each new mouse down (try putting the same thing on post-command-hook and note the difference in delivery time) (defun dtest () (message (format "event(%s:%s) region(activep: %s, contents: '%s')" (event-basic-type last-command-event) (event-modifiers last-command-event) (region-active-p) (buffer-substring (region-beginning) (region-end))))) (add-hook 'deactivate-mark-hook 'dtest) ; (remove-hook 'deactivate-mark-hook 'dtest) * The call was actually reordered recently, but that move only means you get the correct region during the relevant mark deactivation rather than a wierd mix of the old mark to the new point i.e. it's a bugfix (but note that in turn means code depending on it will only work on CVS HEAD at present).