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: 28 Nov 2003 11:53:29 +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 1070018310 26589 80.91.224.253 (28 Nov 2003 11:18:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Nov 2003 11:18:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Nov 28 12:18:26 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 1APgdm-0006AL-00 for ; Fri, 28 Nov 2003 12:18:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1APgdm-0004Re-00 for ; Fri, 28 Nov 2003 12:18:26 +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 1APhaC-0002aj-5c for emacs-devel@quimby.gnus.org; Fri, 28 Nov 2003 07:18:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1APhHK-0007XF-5e for emacs-devel@gnu.org; Fri, 28 Nov 2003 06:59:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1APhGA-00075z-NV for emacs-devel@gnu.org; Fri, 28 Nov 2003 06:58:38 -0500 Original-Received: from [217.80.160.96] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1APhDN-0006FI-2e for emacs-devel@gnu.org; Fri, 28 Nov 2003 06:55:13 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hASArWWJ013296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2003 11:53:32 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hASArTRS013292; Fri, 28 Nov 2003 11:53:29 +0100 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 95 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:18188 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18188 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > > > > In addition, the mouse cursor now changes to an arrow (rather > > > than the text mouse cursor) when it hoovers above an image. > > > > Rationale for that? Just interested. Maybe this should rather > > depend on an appropriate image property? > > That would be an improvement, yes. Will see what I can do. > > The rationale is that the "active point" of text cursor (the > vertical bar) is somewhere in the middle of the vertical line, > i.e. it's no good as a pointer if you want to have precise clicks on > an image. > > 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. Now the question is whether one would want a change of cursor in case such a specific property is _not_ present. One can't see in advance whether the user will call one of the pixel-accurate functions for finding out the position of a click, so we have no clue about the necessity for aiming. Since the position functions are new, as long as we introduce the cursor change properties at about the same time, programmers will have the possibility to get a changed cursor when they want a better aim for their users. Now there is one situation when one _does_ have a change-of-behavior-on-click, and that is when we have a local keymap on the image, in particular one with mouse clicks in it. But this is not really fundamentally different from textual buttons (like the widgets used in customization buffers). So _if_ we get a default cursor change, I think it should be orthogonal to the image issue and rather depend on keymaps. > > > Finally, when you use a block cursor, images are no longer shown > > > in "negative" when your window cursor is a filled block cursor > > > (only the border of the image is highlighted now). So clicking > > > on an image no longer makes it "unreadable"... > > > > Oh great. That means that all the complicated image border > > creation stuff within preview-latex becomes unnecessary, and we'll > > have to check for this functionality conditionally. > > Is this good or bad? It would have been even better if it had been done previously. > > Any good idea for a test for whether the previous terror blinking > > or the new border blinking is used on images? > > Well, in principle, any test that identifies this as GNU Emacs 21.4 > 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. > I suppose you already have checks for different versions in > preview-latex? Mostly not. We have split out the functionality where Emacs and XEmacs differ significantly into separate files (and where they differ only in minor aspects, the XEmacs-specific file defines compatibility macros during byte-compilation), but that's about it. We don't want to have any compile-time checks beyond the basic Emacs/XEmacs dichotomy: we already get enough reports by people trying to use the .elc files compiled with one of them for the other. Telling them to recompile for just upgrading the version would puzzle them completely. > > > > I digress. Anyway, I want more information from clicks. At > > > > the very least, the object they appeared on. > > > > > > What more do you want ? > > 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum