From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: No possibility of determining image position/object from click Date: Sat, 15 Jun 2002 08:13:51 -0600 (MDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200206151413.g5FEDpp10322@aztec.santafe.edu> References: <200206091519.g59FJFk00269@aztec.santafe.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1024150599 18120 127.0.0.1 (15 Jun 2002 14:16:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 15 Jun 2002 14:16:39 +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 17JEM3-0004i9-00 for ; Sat, 15 Jun 2002 16:16:39 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17JElL-0003vQ-00 for ; Sat, 15 Jun 2002 16:42:47 +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 17JELd-0003OQ-00; Sat, 15 Jun 2002 10:16:13 -0400 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17JEJM-0003EP-00; Sat, 15 Jun 2002 10:13:52 -0400 Original-Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g5FEDpQ05245; Sat, 15 Jun 2002 08:13:51 -0600 (MDT) Original-Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g5FEDpp10322; Sat, 15 Jun 2002 08:13:51 -0600 (MDT) X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f Original-To: David.Kastrup@t-online.de In-Reply-To: (David.Kastrup@t-online.de) 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:4883 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4883 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? 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. But I don't understand enough to say that there is no bug here. I am not sure if this is a bug, or an unfortunate consequence of correct Emacs actions, or just what the user deserves. 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. Doesn't that suffice for your immediate goal, which is to use just one keymap for all the images? 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?