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: Several suggestions for image support Date: 17 Apr 2004 20:03:13 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082225112 12631 80.91.224.253 (17 Apr 2004 18:05:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 17 Apr 2004 18:05:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Apr 17 20:05:04 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 1BEuBc-0007Ra-00 for ; Sat, 17 Apr 2004 20:05:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEuBc-0003d5-00 for ; Sat, 17 Apr 2004 20:05:04 +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 1BEuAS-0006ta-Uf for emacs-devel@quimby.gnus.org; Sat, 17 Apr 2004 14:03:52 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BEuAM-0006pl-Bv for emacs-devel@gnu.org; Sat, 17 Apr 2004 14:03:46 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BEu9q-0006S4-DE for emacs-devel@gnu.org; Sat, 17 Apr 2004 14:03:45 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BEu9q-0006S0-7g for emacs-devel@gnu.org; Sat, 17 Apr 2004 14:03:14 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BEu8z-0006np-Nn; Sat, 17 Apr 2004 14:02:22 -0400 Original-To: rms@gnu.org In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 43 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:21823 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21823 Richard Stallman writes: > Emacs should have a way to scroll through an image, > so that C-v each time can advance one window-height > through the image. > > It would be inelegant to handle this by treating the tall > image as several lines--but perhaps that might actually > work more easily than some other methods. I don't think that splitting the image into lines by Emacs itself is feasible: the cursor positions on the image would need to correspond to actual cursor positions in the buffer, or things get inconsistent (Emacs moves out of cursor positions in the image automatically). While it would be a real boost of usability for my main application (preview-latex) if I could walk the cursor across lines or other areas of an image, the correlation between buffer positions and corresponding location of the cursor display would need to get explicitly established by the application: it would imply "stopping points" when Emacs is trying to move the cursor out of visually inaccessible areas. And then Emacs would have to draw a cursor box or other indicator according to the location in there. Substructuring an image like that would be a very nice feature. But I don't see that it is possible to make the decision of where to split an image mechanically. 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. However, the only location where it is currently used is at the end of the buffer. Apart from C-v, scrollbars and mouse wheel currently assume a constant line height, which leads to confusing results where images or other tall lines are concerned. Functions that work in terms of fractions of the window height should try rounding the movement distance down to the next point-addressable line and if that causes the distance to be quite less than asked for, revert to using set-window-vscroll for moving to a partial line. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum