From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: The display margin Date: 24 Nov 2003 10:52:21 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <16080.60869.212521.952911@nick.uklinux.net> <200305251636.h4PGa1ll021935@rum.cs.yale.edu> <16082.42589.935105.932019@nick.uklinux.net> <16321.14941.117864.117597@nick.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069664622 23617 80.91.224.253 (24 Nov 2003 09:03:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2003 09:03:42 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Nov 24 10:03:39 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AOCd9-0005lB-00 for ; Mon, 24 Nov 2003 10:03:39 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AOCd9-0007rl-00 for ; Mon, 24 Nov 2003 10:03:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AODaE-00012E-7z for emacs-devel@quimby.gnus.org; Mon, 24 Nov 2003 05:04:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AODZq-000103-8W for emacs-devel@gnu.org; Mon, 24 Nov 2003 05:04:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AODZJ-0000us-1O for emacs-devel@gnu.org; Mon, 24 Nov 2003 05:04:17 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AODWa-0000Rw-BT for emacs-devel@gnu.org; Mon, 24 Nov 2003 05:00:56 -0500 Original-Received: (qmail 54686 invoked from network); 24 Nov 2003 08:52:43 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 24 Nov 2003 08:52:43 -0000 Original-To: David Kastrup In-Reply-To: Original-Lines: 69 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18073 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18073 David Kastrup writes: > Nick Roberts writes: > > > > I have just checked in fixes to improve event handling for mouse > > > clicks in the marginal areas and on the fringes. Events now have > > > additional information: > > > > > > (WINDOW AREA-OR-POS (X . Y) TIMESTAMP OBJECT POS (COL . ROW)) > > > > > > AREA-OR-POS is not changed as such -- but it may now contain > > > left-fringe and right-fringe. > > > > > > For clicks in the text area, POS is the same as AREA-OR-POS (the > > > buffer position clicked on). For clicks in other areas, POS is > > > the buffer position of the first visible glyph on the > > > corresponding row. > > > > > > As an example, try M-x gdba and click mouse-1 on the left margin > > > or fringe of a source window [it should toggle breakpoint on that > > > line]. > > > > Kim, > > > > I like this very much. > > The click information for GNU Emacs is quite insufficient, anyway. > XEmacs, as far as I can remember, can tell from an event what object > has been clicked on and what pixel relative to the object's origin > has been hit. With GNU Emacs, in contrast, you have to set up a > separate keymap for every object in order to have a chance to find > out which of several ones have been clicked, and no chance of finding > the relative position at all. The OBJECT part of an event (retrievable with the new posn-object function) will give you the object clicked on, that is, if the object you click on is an overlay string or display property string or image, then the string and a character position in that string is returned. I agree that for images, a relative pixel coordiante would be useful too; I'll look into that. > > And the object/click correlation is done at the time when you query > the event, not when the click was done: if you click in order to do a > cut&paste operation on some buffer, and Emacs churns away internally > at the time, finally places a dialog box "Explode now?" on the > screen, then finally processes the click event, it will associate at > it with the exploding object instead of what was on the screen at the > time of the click. Yes, that may be true -- mouse events are put into the normal input queue, so if there are other events (like async process i/o) going on before emacs processes the input queue, it may hit the wrong object before it gets a change to process it. But I don't quite follow the line of thought above; emacs must have processed the mouse event if it displays an "Explode now?" dialog box; and as such, it must have a handle to the clicked-on object prior to showing that dialog box. Can you show me a piece of code which demonstrates the problem? > > I digress. Anyway, I want more information from clicks. At the > very least, the object they appeared on. Doesn't this work with my latest changes? ++kfs