From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: E Sabof Newsgroups: gmane.emacs.bugs Subject: bug#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 19:09:20 +0000 Message-ID: <87mw89a07z.fsf@gmail.com> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> <8338a1y377.fsf@gnu.org> <87ppd5a46w.fsf@gmail.com> <831tplxy1x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414955425 11811 80.91.229.3 (2 Nov 2014 19:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 19:10:25 +0000 (UTC) Cc: 18923@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 20:10:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xl0Xb-0002Sq-1j for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 20:10:19 +0100 Original-Received: from localhost ([::1]:58959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl0Xa-0008E2-I7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 14:10:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl0XS-0008Dg-3g for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 14:10:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xl0XL-0005wH-ID for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 14:10:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xl0XL-0005ve-Ff for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 14:10:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xl0XK-0003od-N2 for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 14:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: E Sabof Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Nov 2014 19:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18923-submit@debbugs.gnu.org id=B18923.141495537014615 (code B ref 18923); Sun, 02 Nov 2014 19:10:02 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 19:09:30 +0000 Original-Received: from localhost ([127.0.0.1]:46383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl0Wo-0003nf-4x for submit@debbugs.gnu.org; Sun, 02 Nov 2014 14:09:30 -0500 Original-Received: from mail-wg0-f44.google.com ([74.125.82.44]:33691) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl0Wl-0003nP-OB for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 14:09:28 -0500 Original-Received: by mail-wg0-f44.google.com with SMTP id x12so9122393wgg.17 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 11:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; bh=OU3N/uOC0qcqc1YrXUtl9PlAWIVsyBHKivL0V26pO/g=; b=0KOLukfCuJRivO34dX825bv5tO4aTSAErpSwA7O5BaRdfcCweFjVy6crEEgSt7JKfZ /U+Tdmn2pdI0VXePscX8RtvaA2ZEPX/mFYSacjWVm3irD/25GDf6w2KYP8+T3R/4aqRq kjiTtcdRbqB5evZ5tbem60uKM1lH5pzYdO0Jj1KBKrYHuyJBAVXjzaFrMoeHxT/iPp2m OeiVrb0MWX7mPcd4fPPkFq5r8TztHVuALeQ0XtWwPFHim8f0lCcfTIJZe0Xy3iB4X1HK RUWTkZJYDvxKaiitlD2TJ48XirF1S8oPAW8D45SvovJTJZPtci5iYQLSBdH/M0ynl2oH ulHA== X-Received: by 10.180.81.134 with SMTP id a6mr11041785wiy.11.1414955362027; Sun, 02 Nov 2014 11:09:22 -0800 (PST) Original-Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id bc1sm5419147wib.16.2014.11.02.11.09.20 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 11:09:21 -0800 (PST) In-reply-to: <831tplxy1x.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95397 Eli Zaretskii writes: > > Imagine there is a buffer with **AN IMAGE** which occupies 30% of the window (ex. a diagram in an org-mode buffer). It's positioned at (window-start). I (scroll-up 1). I'd end up scrolling a lot more than the usual (= (default-line-height) 20) pixels, which is what I mean by "jump". > If the problem is only with scrolling by single lines (or small > number of lines), then a very similar problem is already solved in > line-move-partial. Try C-n in the same situation, and see if that's > what you want. We could then use the same technique. I'm not sure that we are talking about the same scenario. I didn't encounter any relevant behavior while using C-n/C-p, when a large image was displayed on the first line (with my default settings or Emacs -Q, both on the latest stable release). > The problem that you faced, as I understand it, was to get the pixel > size of a screen line even if it is only partially visible. The RTOP > and RBOT values returned by pos-visible-in-window-p give you > information about how many pixels of the line are above the top and > below the bottom of the window. (For a very tall image or a low > window, both RTOP and RBOT will be non-zero.) Add those to the > visible height of the line, and AFIU you get what you wanted. Am I > missing something? Maybe not. >> > IME, the most important use case is scrolling by "almost the full >> > window", in which case it is better to start with window-body-height >> > and subtract from it, instead of starting with zero and add to it. >> > The most expensive part here is vertical-motion, so I think you want >> > to call it as little as possible. >> >> window-body-height can be very wrong if a large image is displayed in the buffer. > > I meant call window-body-height with PIXELWISE non-nil. Then the > return value doesn't depend on what is displayed, it just gives you > the height of the text area in pixels. Subtracting from that the > pixel coordinates of point returned by pos-visible-in-window-p or > posn-at-point will give you how many pixels are there to the top and > bottom of the window. This should eliminate the need to count pixels > by moving one screen line at a time via vertical-motion, which is less > efficient, I think. I'm not sure how knowing the distance of a point to the bottom of the window would benefit me, but indeed I could bulk-measure several lines in some cases. Evgeni