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: 09 Jun 2002 22:36:08 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200206091519.g59FJFk00269@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 1023655194 8953 127.0.0.1 (9 Jun 2002 20:39:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 9 Jun 2002 20:39:54 +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 17H9Te-0002KI-00 for ; Sun, 09 Jun 2002 22:39:54 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17H9qA-00034w-00 for ; Sun, 09 Jun 2002 23:03:10 +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 17H9Sr-0004Ph-00; Sun, 09 Jun 2002 16:39:05 -0400 Original-Received: from mailout04.sul.t-online.com ([194.25.134.18]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17H9RJ-0004K5-00; Sun, 09 Jun 2002 16:37:29 -0400 Original-Received: from fwd03.sul.t-online.de by mailout04.sul.t-online.com with smtp id 17H9RH-0005yg-02; Sun, 09 Jun 2002 22:37:27 +0200 Original-Received: from tupik.goethe.zz (520018396234-0001@[217.80.157.230]) by fwd03.sul.t-online.com with esmtp id 17H9R5-1ccWYqC; Sun, 9 Jun 2002 22:37:15 +0200 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g59Ka8501744; Sun, 9 Jun 2002 22:36:08 +0200 Original-To: rms@gnu.org In-Reply-To: <200206091519.g59FJFk00269@aztec.santafe.edu> Original-Lines: 90 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:4672 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4672 Richard Stallman writes: > GNU Emacs is missing an API for finding out where a click occured. If > I have a string or an image as part of a display property, or as a > before-string or after-string, the only way to let Emacs react to > clicks on different images differently is to generate individual > keymaps for each of them. I have also encountered another "bug" in connection with that for which an actual example is pretty hard to produce: if a displayed window changes asynchronously because a sentinel is placing image properties on screen, and Emacs is basically busy without getting to redisplay, then tooltip displays (for example) will still pop up for whatever the mouse cursor is covering, as a user would expect. 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 not sure this would be easy to fix: it would probably imply having to associate things of relevance (object clicked on, buffer position and a few other things) to an event at the time of the click, or at least before redisplay destroys the information about the screen state at the time of the event. > I see. All it provides is the buffer position, which won't tell > you the position within the before-string. 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). This is quite similar to the before-string problem, except that in that case one does not have a string-object easily available with which to associate. > I think we should replace the buffer position with a list that gives > the full story. > > Even then, you cannot find out the > relative coordinates of a click on such an image. > > It does give the x and y pixel coordinates of the click. If you can > determine the coordinates of a corner of the image, at the time of the click... > you can subtract and get the relative position. But I am not sure > there is any way to determine the corner's coordinates, if the image > comes from a before-string. At least I have failed to see one. > In principle, these are good features to add. Do you have an > immediate practical application for them? Well, as you should remember from the amounts of display engine related bug reports I sent in before Emacs-21.1 got released, I have employed Emacs-21's new display engine for providing WYSIWYG-like editing of LaTeX compositions (formulas, section headings, figures and other configurable stuff). Info/homepage/downloads at . Currently, we trace clicks back to single images by giving each of them an individual keymap with a keybinding to a quoted function call including the image overlay. It would be quite more convenient if all images could just get the same keybinding. A future plan is to provide relative positioning: click close to the bottom of such an image, and you get placed close to the lower border of the source text. Another would be table editing: those are currently one big image. I could get the LaTeX component of preview-latex to deliver the relative pixel coordinates in such a table to Emacs, so that I can reliably edit a particular table cell in the source code when the image gets clicked. All of those refinements would require the relative position of the click on the image. The keymap tomfoolery has made it at least possible to identify the image itself reliably, but the position appears quite out of reach for me at the current point of time. Would you be interested in getting info about the functions XEmacs uses for reporting those properties of events, so that programmers of external packages will have less work in order to make their stuff work under both Emacsen? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@t-online.de