From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: The display margin Date: 29 Nov 2003 12:37:13 +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 1070105948 15467 80.91.224.253 (29 Nov 2003 11:39:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Nov 2003 11:39:08 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Nov 29 12:39:05 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 1AQ3RJ-0006AC-00 for ; Sat, 29 Nov 2003 12:39:05 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AQ3RJ-00035f-00 for ; Sat, 29 Nov 2003 12:39:05 +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 1AQ4Nm-0001po-Qw for emacs-devel@quimby.gnus.org; Sat, 29 Nov 2003 07:39:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AQ4Ng-0001pY-RS for emacs-devel@gnu.org; Sat, 29 Nov 2003 07:39:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AQ4NA-0001Ky-3P for emacs-devel@gnu.org; Sat, 29 Nov 2003 07:39:23 -0500 Original-Received: from [217.80.160.72] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AQ4N9-0001Jp-DW for emacs-devel@gnu.org; Sat, 29 Nov 2003 07:38:51 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hATBbISU015427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2003 12:37:18 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hATBbEdi015423; Sat, 29 Nov 2003 12:37:14 +0100 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 52 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:18204 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18204 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > > > storm@cua.dk (Kim F. Storm) writes: > > > > > But of course, if that image is showing text, a text cursor may > > > still make sense... > > > > In general, a change of cursor is an indicator that the behavior of > > clicking will change. Since different cursors might indicate > > different behaviors, it certainly makes sense to have this as a > > separate property. > > I will add both a generic 'pointer' text property, and a specific > image :pointer property. > > Maybe also an image :keymap property, but that will require more > work, so I will have to investigate further before doing so. I've been using keymaps on images for years already (via the display property or so). It was the only way to make an image clickable since you could not enquire whether a click position was on an image or on text beside it (at least for images on zero-width overlays). > > > or newer would do... But if you want something which really > > > narrows down when this was introduced, (fboundp > > > 'posn-object-x-y) will do. > > > > This has such an _indirect_ flavor to it. Let's hope that nobody > > does a branch having one but not the other feature. > > Sure. Maybe (boundp 'void-text-area-pointer) will be better as it's > in the C code [will be when my current fixes are committed in a few > days]. Guess we'll find something. > > > I was just asking in the context of "required information in > > > mouse click events". Your answer seems to be "nothing further". > > > > Actually, given that we now have a pixel-accurate position within > > the object (maybe this is generalizable in some manner also for > > text?), it would be nice having a way of knowing the > > pixel-accurate size of a displayed object in the first place so > > that one can calculate the relative position in the image easily, > > too. > > I'll look into adding this info as well ... at least for images. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum