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: 27 Nov 2003 23:30:11 +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 1069972324 29771 80.91.224.253 (27 Nov 2003 22:32:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 27 Nov 2003 22:32:04 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 27 23:32:01 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 1APUg5-00009K-00 for ; Thu, 27 Nov 2003 23:32:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1APUg5-0004x4-00 for ; Thu, 27 Nov 2003 23:32:01 +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 1APVcW-000447-0x for emacs-devel@quimby.gnus.org; Thu, 27 Nov 2003 18:32:24 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1APVcR-00043e-1L for emacs-devel@gnu.org; Thu, 27 Nov 2003 18:32:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1APVbv-0003zW-64 for emacs-devel@gnu.org; Thu, 27 Nov 2003 18:32:18 -0500 Original-Received: from [217.80.157.138] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1APVbu-0003zO-Da for emacs-devel@gnu.org; Thu, 27 Nov 2003 18:31:47 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hARMUBDt011442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2003 23:30:12 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hARMUBfN011438; Thu, 27 Nov 2003 23:30:11 +0100 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 73 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:18177 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18177 storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > > > The click information for GNU Emacs is quite insufficient, anyway. > > XEmacs, as far as I can remember, can tell from an event what object > > has been clicked on and what pixel relative to the object's origin > > has been hit. > > I have just added this information to mouse clicks and two functions to > access it: > > Function `posn-object' returns the object clicked on, either an image > or a cons (string . pos), or nil if there is nothing special at the > place where you click the mouse (use posn-point to look at that). > > Function `posn-object-x-y' return a cons (dx . dy) which is the pixel > coordinates relative to the top left corner of the object (image or > character) that you click on. > > 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? > 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. Any good idea for a test for whether the previous terror blinking or the new border blinking is used on images? > > I digress. Anyway, I want more information from clicks. At the > > very least, the object they appeared on. > > What more do you want ? Well, further preview-latex usability problems are that Emacs often goes ballistic when large height images are concerned, particularly larger than window size images. Scrolling those to a particular viewing position is pretty much impossible, scrollbar interaction is nonworkable, and scroll-wheel stuff is pretty much unpredictable as well (there have been Emacs versions where wheel-use could lead to lockup with large images, I am not sure whether this is currently the case). When using XEmacs on such images, repeated use of Pagedown scrolled larger-than-window images through at a pace of about one normal line height per keypress. While this was far from scrolling a window worth of material, at least the scrolling made some progress and one had a possibility to see all parts of such an image. In contrast, IIRC, Emacs does not even touch the window-vscroll value (which would move by a fraction of the image) unless at the very end of buffer. One possibility to see the effect it to use C-h i d m Emacs RET C-x 2 and drag the mode line of the upper window such that the "Emacs" headline is only partially visible. Repeated presses of C-v will then stop on the headline and not make any more progress. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum