From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: No possibility of determining image position/object from click Date: 15 Jun 2002 16:34:25 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200206091519.g59FJFk00269@aztec.santafe.edu> <200206151413.g5FEDpp10322@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1024151797 19492 127.0.0.1 (15 Jun 2002 14:36:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 15 Jun 2002 14:36:37 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17JEfN-00054F-00 for ; Sat, 15 Jun 2002 16:36:37 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17JF4f-0004Mh-00 for ; Sat, 15 Jun 2002 17:02:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JEez-0004Zh-00; Sat, 15 Jun 2002 10:36:13 -0400 Original-Received: from mailout11.sul.t-online.com ([194.25.134.85]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JEeh-0004Y2-00; Sat, 15 Jun 2002 10:35:56 -0400 Original-Received: from fwd05.sul.t-online.de by mailout11.sul.t-online.com with smtp id 17JEeg-0007bK-04; Sat, 15 Jun 2002 16:35:54 +0200 Original-Received: from tupik.goethe.zz (520018396234-0001@[62.226.11.189]) by fwd05.sul.t-online.com with esmtp id 17JEeT-03Rw36C; Sat, 15 Jun 2002 16:35:41 +0200 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g5FEYPG02177; Sat, 15 Jun 2002 16:34:25 +0200 Original-To: rms@gnu.org In-Reply-To: <200206151413.g5FEDpp10322@aztec.santafe.edu> Original-Lines: 67 X-Sender: 520018396234-0001@t-dialin.net Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4886 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4886 Richard Stallman writes: > If one > does an actual _click_ on such an image, the positions(?) but at least > the keymaps that get consulted for this click are the keymaps that > belong to the display _after_ Emacs updates the screen. This means, > for example, that you were sure to click on an image in the buffer > (and display and corresponding tooltip suggested you would), but if > Emacs actually gets to look at the click, it will instead yank the cut > buffer into a different location than that at the time of the click. > > I am trying to read this and understand it, but having trouble parsing > it. I can't really grasp the sequence of user actions and Emacs > behaviors. > > It seems correct that Emacs uses the latest data to interpret a click; > what else should it do? Emacs uses data to interpret a click that has not yet made it to the screen at the moment of the click. > If the text is changing rapidly, in general you are taking a risk by > clicking on it, since what you intended to click on could have moved > or changed by the time the mouse button makes contact. This is not the problem, since this would just introduce a small time window for thwarting the user. But Emacs does not update the screen while it is busy, which can easily last for a few seconds. If I click onto the screen during that time, buffer positions and keymaps will be calculated corresponding to what the screen will look like after the next screen update finally gets done. This is hardly what the user intended when clicking onto something. Of course, there is a problem for Emacs if the object displayed at the time of the click has already been deleted, but this deletion has not yet been reflected by a display update. > Also, if a larger body of text is displayed as an image by way > of a 'display property, the buffer position does not buy me > anything (it will probably be that of the first letter of the > text). > > The buffer position tells you what image was clicked on. No. I might have more than one image at a specific buffer position, I might have overlays not covering any character. The buffer position will not tell me whether I clicked on the image of an empty overlay, or on the character following it, or on which image from several overlays at the same character position, or on some before-string or after-string property of an overlay. > Doesn't that suffice for your immediate goal, which is to use just > one keymap for all the images? Not really as well as to warrant changing the current behavior. > We could add the relative position within in the image to the event, > and we could add other things to the event too. Would someone like > to propose an upward compatible data representation that does the > whole job? I would guess the internal structure of events need not be so very much upward compatible as long as the interface routines to it (like posn-xy or similar) returned the same values as before. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@t-online.de