From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 20:22:18 +0200 Message-ID: <831tplxy1x.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> <8338a1y377.fsf@gnu.org> <87ppd5a46w.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414952606 1907 80.91.229.3 (2 Nov 2014 18:23:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 18:23:26 +0000 (UTC) Cc: 18923@debbugs.gnu.org To: E Sabof Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 19:23:18 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 1Xkzo6-0002eO-FX for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 19:23:18 +0100 Original-Received: from localhost ([::1]:58850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkzo6-0006ny-0p for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 13:23:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkznw-0006np-Nm for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:23:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xkznq-00010Q-QD for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:23:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkznq-00010M-ME for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xkznq-0002aN-AA for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Nov 2014 18:23: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.14149525619906 (code B ref 18923); Sun, 02 Nov 2014 18:23:02 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 18:22:41 +0000 Original-Received: from localhost ([127.0.0.1]:46352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkznU-0002Zh-VX for submit@debbugs.gnu.org; Sun, 02 Nov 2014 13:22:41 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:55833) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkznR-0002ZQ-VD for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 13:22:39 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NEF00C00C55GM00@a-mtaout21.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 20:22:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00CO3CDIF040@a-mtaout21.012.net.il>; Sun, 02 Nov 2014 20:22:30 +0200 (IST) In-reply-to: <87ppd5a46w.fsf@gmail.com> X-012-Sender: halo1@inter.net.il 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:95392 > From: E Sabof > Cc: 18923@debbugs.gnu.org > Date: Sun, 02 Nov 2014 17:43:35 +0000 > > Imagine there is a buffer with 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. > >> >> (defun st-height (&optional pos) > >> >> "Won't report accurately, if the line is higher than window." > >> >> (cl-flet (( posn-y () > >> >> (cdr (posn-x-y (or (posn-at-point) > >> >> (progn > >> >> (vertical-motion 0) > >> >> (set-window-start nil (point)) > >> >> (posn-at-point))))))) > >> > > >> > Did you try using pos-visible-in-window-p? I think it's what you > >> > want. > >> > >> Reading through the documentation of `pos-visible-in-window-p' didn't suggest how it could be useful. > > > > Do you still not understand that? If so, I will elaborate why I think > > that function is what you want. > > My best guess is that I'd still have to go through a similar procedure of comparing 2 return values for lines that have to be at least partially visible from some position, but I would get more information on partially visible lines. I haven't thought-through all the cases, but it might indeed always work. 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? > > 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. > Still some heuristics could be used to speed-up the most common case, all lines being ~= (default-line-height). This problem is also solved by working in pixels, which is what your code did anyway. > > I think we need to decide first whether the slowdown is acceptable. > > IMO it is too significant to be ignored, if we want to replace > > existing code. > > I could define some limit (the pixel height of a window?), and if it was to be exceeded, I'd fall back on the existing or similar approach. I don't know how often people scroll several pages, but it's likely that if they do they would value speed over accuracy. AFAIU, your method isn't more accurate than the existing one, except in case of images. If scrolling images by single lines is the issue, I'm quite sure we can have that with the current C implementation. So I think the issue of whether the slower speed is acceptable still stands. If it is acceptable, then the Lisp implementation should be improved and enhanced; if it isn't, then the C implementation should be improved.