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 18:31:08 +0200 Message-ID: <8338a1y377.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414945948 32406 80.91.229.3 (2 Nov 2014 16:32:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 16:32:28 +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 17:32:20 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 1Xky4h-0002Pe-Pk for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 17:32:19 +0100 Original-Received: from localhost ([::1]:58049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xky4h-0001X8-Dd for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 11:32:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xky4Y-0001WX-9n for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 11:32:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xky4S-0002Ea-BG for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 11:32:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xky4S-0002EQ-8O for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 11:32:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xky4P-00086w-Ug for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 11:32:01 -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 16:32:01 +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.141494591131158 (code B ref 18923); Sun, 02 Nov 2014 16:32:01 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 16:31:51 +0000 Original-Received: from localhost ([127.0.0.1]:46281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xky3w-000864-IK for submit@debbugs.gnu.org; Sun, 02 Nov 2014 11:31:51 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:49630) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xky3r-00085h-Bg for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 11:31:31 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NEF00G0076FWN00@a-mtaout20.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 18:31:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00G3R788O740@a-mtaout20.012.net.il>; Sun, 02 Nov 2014 18:31:20 +0200 (IST) In-reply-to: <87r3xla7zw.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:95384 > From: E Sabof > Cc: 18923@debbugs.gnu.org > Date: Sun, 02 Nov 2014 16:21:23 +0000 > > > What are the advantages of this alternative way of scrolling, beyond > > being in Lisp and eliminating the jumps when encountering an image? > > (Btw, a test case for the latter would be nice, perhaps as a separate > > bug report.) If the only advantage is better handling of in-line > > images, then perhaps fixing the existing implementation is a better > > path forward? > > There aren't. Do you have ideas on how this could be accommodated? Technically Sorry, I'm not sure I understand the question. If you mean how to avoid jumps with the existing C implementation when there are inline images, then please show a recipe to see the problem, and let's take it from there. > >> (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. > A more descriptive name for the function would be `st-get-pixel-height-of-line-at-point'. Yes, I think I understood that. > >> (cl-loop do (push (st-height) rows) > >> until (or (zerop (vertical-motion direction)) > >> ;; >= ? > >> (>= (cl-reduce '+ rows) > >> (abs ammount)))) > > > > I don't understand why you needed this loop. Can't you use > > window-body-height instead? > > What I need mostly depends on the amount of pixels I want to scroll - (for 2 "normal" lines, this loop would run twice) which is usually less than window-body-height, but could potentially be more. 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. > > This doesn't support the equivalent of a nil argument, which means > > move by "near full screen". > > I can implement this if the overall approach gets a green light. 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.