From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Several suggestions for image support Date: 19 Apr 2004 12:34:40 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87zn98ybzl.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082363970 15162 80.91.224.253 (19 Apr 2004 08:39:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Apr 2004 08:39:30 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Apr 19 10:39:17 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BFUJB-0004zA-00 for ; Mon, 19 Apr 2004 10:39:17 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BFUJB-0000Tw-00 for ; Mon, 19 Apr 2004 10:39:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BFUHp-0006dp-7O for emacs-devel@quimby.gnus.org; Mon, 19 Apr 2004 04:37:53 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BFUGU-0005XZ-Vj for emacs-devel@gnu.org; Mon, 19 Apr 2004 04:36:30 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BFUFn-0004yT-Hp for emacs-devel@gnu.org; Mon, 19 Apr 2004 04:36:18 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.30) id 1BFUFG-0004j8-0R for emacs-devel@gnu.org; Mon, 19 Apr 2004 04:35:14 -0400 Original-Received: (qmail 58268 invoked from network); 19 Apr 2004 08:35:01 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 19 Apr 2004 08:35:01 -0000 Original-To: David Kastrup In-Reply-To: Original-Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:21874 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21874 David Kastrup writes: > Stefan Monnier writes: > > > >> Of course, scrolling through large images should be possible, anyway, > > >> and quite independent from that fanciful features. Emacs already has > > >> set-window-vscroll in its display engine in order to deal perfectly > > >> well with that. > > > Yes, and it could probably be done entirely in lisp !? > > > > I already suggested to use two new primitives (that have incidentally > > been requested for other purpose): > > > > point-to-pixel > > and > > pixel-to-point > > > > which turn a (displayed) buffer position into a display position and vice > > versa. All the rest should then be reasonably easy to do in Elisp. > > I don't see how. Absolutely not. Emacs moves point out of images. > Without stopping points, point will not remain inside of the image > anywhere. At least it could deal sensible with vscrolling through a partially visible image without moving point out of the image until there is some other visible line to move it to. Stefan, isn't it be necessary to have some indication of whether vscrolling will have any effect, i.e. whether the cursor line is currently fully visible, or if there are N pixels invisible at the top and M pixels invisible at the bottom? E.g. a current-row-visibility function which returns nil if fully visible and a cons (N . M) otherwise. > And I certainly can't draw a cursor box over a selected > area of an image. Or have mouse highlighting over a selected area. My image slice changes allows you to do exactly that, as each slice of the image is inserted as a separate display property. Re. image maps, I decided that for an image slice, the code still references the image map of the full image, but restricted to the current slice. So if you want each image slice to have specific properties, you must create an image map corresponding to the actual slicing of the image. Of course, you may also put properties on each slice, as each slice corresponds to a separate buffer position. I will try to complete my changes during this week. > > I am still thinking about Kim's proposal (horizontal slices with > vertical subslices) with regard to use under preview-latex. It would > certainly cater for pretty much every important application I > currently have in mind. Doing "free positioning (and rotation/orientation/scaling)" of images and text is on my to-do list for 22.x. -- Kim F. Storm http://www.cua.dk