From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 01 21:16:37 2014 Received: (at submit) by debbugs.gnu.org; 2 Nov 2014 01:16:37 +0000 Received: from localhost ([127.0.0.1]:44912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkjmV-0006Df-Se for submit@debbugs.gnu.org; Sat, 01 Nov 2014 21:16:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37432) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkjmO-0006D9-S4 for submit@debbugs.gnu.org; Sat, 01 Nov 2014 21:16:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XkjmA-0003jf-Hn for submit@debbugs.gnu.org; Sat, 01 Nov 2014 21:16:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkjmA-0003jb-EV for submit@debbugs.gnu.org; Sat, 01 Nov 2014 21:16:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkjm1-0008U1-8t for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 21:16:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xkjls-0003hm-49 for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 21:16:05 -0400 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:54907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkjlr-0003he-Pb for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 21:15:56 -0400 Received: by mail-wi0-f172.google.com with SMTP id bs8so3915382wib.11 for ; Sat, 01 Nov 2014 18:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type; bh=BZZkluwX4sD68jHjX/oaNjcMxxS/E78GIqnXfxhZ0Z0=; b=UeOIKc+a7rPBMBUYDUExyzgwgSusylW9y0ufJDvhEJhzidf1c65gcNVQ1w2AqL1RVY c4rOKsY7JOQL0PwkdPt1nu+bNgwNd5sJN6tOdgMboS0bqWU17orIHF4/8wNXMkosUJGR 4SveathCeET/X7ZWpl9bs934u1KLmEq7Uo9zcn1BfSgtHIx278iykFb8xBQhbixpPObK nLB4FZ8Eh4HhVIvagiNHJAZUdby1v467v5Dib6tcD0P+M7EurKWB36PSUT82MWPB6Y7n PaZlyErHR8dhHBP2wHztERT5WmL9Vkj2rB3eVE0g+Z9u/QHgEbiSYkPD8D0lBl/LexAa Zrww== X-Received: by 10.180.182.195 with SMTP id eg3mr6813800wic.31.1414890954548; Sat, 01 Nov 2014 18:15:54 -0700 (PDT) Received: from ubuntu ([31.185.153.108]) by mx.google.com with ESMTPSA id bc1sm2812065wib.16.2014.11.01.18.15.53 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 01 Nov 2014 18:15:53 -0700 (PDT) From: E Sabof To: bug-gnu-emacs@gnu.org Subject: Alternative scrolling model Date: Sun, 02 Nov 2014 01:15:52 +0000 Message-ID: <87wq7e9zcn.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) I've made a prototype for an alternative way to scroll. Essentially scrolling is done pixelwise irrespective of content. Whole lines are scrolled "normally", and the remainder is vscrolled. If the end result is close to a line boundary it gets "snapped" to it. This prevents unpleasant jumping when encountering an image. It doesn't handle the "image taller than window" case, but it would if `st-height' could measure more accurately. Evgeni ;; Any vscroll adjustements will be reset by line-move (require 'cl-lib) (defun st-message (&rest args) ;; (apply 'message args) ) (defvar st-ov nil) (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))))))) (save-excursion (save-window-excursion (let* ((ws (window-vscroll nil t)) a b) (when (cl-plusp ws) (set-window-vscroll nil 0 t)) (setq a (posn-y)) (vertical-motion 1) (setq b (posn-y)) (when (cl-plusp ws) (set-window-vscroll nil ws t)) (- b a) ))))) (cl-defun st-get-lines (ammount) "Provide the information required to scroll by AMMOUNT. AMMOUNT can be positive, if scrolling towards the end of the buffer, or negative otherwise. Returns \(list vscroll \(list lines\)\), where \"vscroll\" is the current \(window-vscroll\) and \"lines\" are the lines are enogh or more lines required for to scroll." (let* (( direction (if (cl-plusp ammount) 1 -1)) ( vscroll (window-vscroll nil t)) rows) (save-excursion (goto-char (window-start)) (cl-incf ammount vscroll) (when (cl-minusp direction) (unless (cl-minusp ammount) (cl-return-from st-get-lines (list vscroll nil))) (vertical-motion -1)) (cl-loop do (push (st-height) rows) until (or (zerop (vertical-motion direction)) ;; >= ? (>= (cl-reduce '+ rows) (abs ammount)))) (list vscroll (nreverse rows))))) (cl-defun st-move (lines vscroll) ;; vscroll changes aren't always displayed. Haven't found a work-around for this. (let (( ori-point (point)) ( new-ws (save-excursion (goto-char (window-start)) (vertical-motion lines) (point)))) (progn (set-window-start nil new-ws) ;; If I don't do this, vscroll might get reset to 0 ;; (point) might change after this ;; (window-start) might change after this, if the cursor is positioned on ;; that image, and scrolling down. This always happends if image would be ;; split at the bottom, but sometimes it happens earlier. What follows is ;; a work-around. (redisplay t) (when (/= (window-start) new-ws) ;; (message "HIT") (vertical-motion -1) (set-window-start nil new-ws) (redisplay t) ) ) (set-window-vscroll nil vscroll t) ;; Prevents flashes of incorrectly positioned images ;; (window-start) might change after this, if the cursor is on an image and ;; it might get divided on the upper edge (redisplay t) (when (/= (window-start) new-ws) ;; (message "HIT2") (vertical-motion 1) (set-window-start nil new-ws) (redisplay t) ) )) (cl-defun scroll--backtick (&optional (arg 1) pixelwise snap) (interactive) (let* (( default-height (default-line-height)) ( pixels-to-move (if pixelwise arg (* arg default-height))) ( snap (or snap (/ default-height 2))) ( line-info (st-get-lines (- pixels-to-move))) ( heights (cadr line-info)) ( initial-vscroll (car line-info)) ( excess 0) enough-or-too-many-heights too-few-heights) (if (<= pixels-to-move initial-vscroll) (progn (setq heights nil excess (- initial-vscroll pixels-to-move))) (cl-decf pixels-to-move initial-vscroll) (setq enough-or-too-many-heights (cl-reduce '+ heights) too-few-heights (cl-reduce '+ (butlast heights) :initial-value 0)) (cond ( (= enough-or-too-many-heights pixels-to-move) (st-message "Exact %s" heights) ) ( (> pixels-to-move enough-or-too-many-heights) (st-message "Near edge %s > %s" pixels-to-move enough-or-too-many-heights) (setq excess 0)) ( (<= (- enough-or-too-many-heights snap) pixels-to-move) (st-message "Snap out") (setq excess 0)) ( (and (cl-plusp too-few-heights) (>= (+ too-few-heights snap) pixels-to-move)) (st-message "Snap in %s" heights) (setq excess 0) (setq heights (butlast heights)) ) ( t (st-message "Default") (setq excess (- enough-or-too-many-heights pixels-to-move)) ))) (st-move (- (length heights)) excess) )) (cl-defun scroll-tick (&optional (arg 1) pixelwise snap) (interactive) (cond ( (zerop arg) (cl-return-from scroll-tick)) ( (< arg 0) (cl-return-from scroll-tick (scroll--backtick (- arg) pixelwise snap)))) (when st-ov (delete-overlay st-ov)) (let* (( default-height (default-line-height)) ( pixels-to-move (if pixelwise arg (* arg default-height))) ( snap (or snap (/ default-height 2))) ( line-info (st-get-lines pixels-to-move)) ( heights (cadr line-info)) ( initial-vscroll (car line-info)) excess enough-or-too-many-heights too-few-heights) (cl-incf pixels-to-move initial-vscroll) (setq enough-or-too-many-heights (cl-reduce '+ heights) too-few-heights (cl-reduce '+ (butlast heights) :initial-value 0) excess (if (= enough-or-too-many-heights pixels-to-move) 0 (- pixels-to-move too-few-heights))) (cond ( (= enough-or-too-many-heights pixels-to-move) (st-message "Exact %s" heights) ) ( (> pixels-to-move enough-or-too-many-heights) (st-message "Near edge") (setq excess 0)) ( (<= (- enough-or-too-many-heights snap) pixels-to-move) (st-message "Snap out") (setq excess 0)) ( (and (cl-plusp too-few-heights) (>= (+ too-few-heights snap) pixels-to-move)) (st-message "Snap in %s" heights) (setq excess 0) (setq heights (butlast heights)) ) ( t (st-message "Default") (setq heights (butlast heights)) )) (st-move (length heights) excess) )) ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick 10))) ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick -10))) ;; TESTS ;; (require 'noflet) ;; (ert-deftest scroll-tick () ;; (noflet (( st-move (&rest args) args)) ;; (noflet (( st-get-lines (arg) ;; '(0 (30)))) ;; ;; Simple V-scroll ;; (should (equal (scroll-tick 5 t 0) ;; '(0 5))) ;; ;; Simple exact ;; (should (equal (scroll-tick 30 t 0) ;; '(1 0))) ;; ) ;; (noflet (( st-get-lines (arg) ;; '(0 (5 30)))) ;; ;; Complete line + vscroll ;; (should (equal (scroll-tick 15 t 0) ;; '(1 10))) ;; ;; Complete 2 lines ;; (should (equal (scroll-tick 35 t 0) ;; '(2 0))) ;; ) ;; (noflet (( st-get-lines (arg) ;; '(5 (10 20)))) ;; ;; ;; (should (equal (scroll-tick 20 t 0) ;; '(1 15))) ;; ;; Complete 2 lines ;; (should (equal (scroll-tick 25 t 0) ;; '(2 0))) ;; )) ;; ) ;; (ert-deftest scroll-backtick () ;; (noflet (( st-move (&rest args) args)) ;; (noflet (( st-get-lines (arg) ;; '(0 (30)))) ;; ;; Simple V-scroll ;; (should (equal (scroll-tick -5 t 0) ;; '(-1 25))) ;; ;; Simple exact ;; (should (equal (scroll-tick -30 t 0) ;; '(-1 0)))) ;; (noflet (( st-get-lines (arg) ;; '(0 (5 30)))) ;; ;; Complete line + vscroll ;; (should (equal (scroll-tick -15 t 0) ;; '(-2 20))) ;; ;; Complete 2 lines ;; (should (equal (scroll-tick -35 t 0) ;; '(-2 0))) ;; ) ;; (noflet (( st-get-lines (arg) ;; '(5 (10)))) ;; ;; Scroll across existing vscroll + a bit ;; (should (equal (scroll-tick -10 t 0) ;; '(-1 5))) ;; ) ;; (noflet (( st-get-lines (arg) ;; '(5 (10 20)))) ;; ;; Scroll up a bit ;; (should (equal (scroll-tick -1 t 0) ;; '(0 4))) ;; ;; Remove vscroll ;; (should (equal (scroll-tick -5 t 0) ;; '(0 0))) ;; ;; ;; (should (equal (scroll-tick -20 t 0) ;; '(-2 15))) ;; ) ;; ) ;; ) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 01 22:31:58 2014 Received: (at submit) by debbugs.gnu.org; 2 Nov 2014 02:31:58 +0000 Received: from localhost ([127.0.0.1]:44960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkkxS-0001jj-0k for submit@debbugs.gnu.org; Sat, 01 Nov 2014 22:31:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45024) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkkxP-0001jV-9x for submit@debbugs.gnu.org; Sat, 01 Nov 2014 22:31:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XkkxE-0007Rz-Ly for submit@debbugs.gnu.org; Sat, 01 Nov 2014 22:31:50 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkkxE-0007Rt-JC for submit@debbugs.gnu.org; Sat, 01 Nov 2014 22:31:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkkx9-00007V-0p for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 22:31:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xkkx0-0007Og-QN for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 22:31:38 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:54755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkkx0-0007OU-JO for bug-gnu-emacs@gnu.org; Sat, 01 Nov 2014 22:31:30 -0400 Received: by mail-wg0-f47.google.com with SMTP id a1so10203641wgh.6 for ; Sat, 01 Nov 2014 19:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:subject:date:message-id:mime-version :content-type; bh=RZ9eRBXXZMpuh4ub73gMs6zxTjikqRmWYTk3cA1ec4U=; b=FsqmrtR3ui3SnN1UhgGPenCyVjRY6jSdLegx4OHHevDyLtgE7kF+TzOrrDYa+kBWjR VZTCHv54zk5GUSxC5OUjTiC1ZDlpcg+ofSt0pnwimoYwNHFt4iUdCIuYLl6oomC9iRxX CI8OnPFcpApocNtnALgkM4EsRtyqN8MkZd+ds6cRBIW9p9AjvyL8KPiUJnW1fN2aZNSY R+4hGlPJqyfK4G+d530cp+yT0tVgQkSLhrd1FkAtAGM6GcgCLeDnqQs6u2Myc84J0vtE a//9RBrIokIkvk6z9TOZbGCksYOLlS3AZVcUAjbXuqw0rqXbvQpH0er87WCXTZt5EwM7 fhfw== X-Received: by 10.180.9.106 with SMTP id y10mr6954833wia.30.1414895489753; Sat, 01 Nov 2014 19:31:29 -0700 (PDT) Received: from ubuntu ([31.185.153.108]) by mx.google.com with ESMTPSA id dq7sm3675792wid.12.2014.11.01.19.31.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 01 Nov 2014 19:31:29 -0700 (PDT) References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> From: E Sabof To: bug-gnu-emacs@gnu.org Subject: Re: bug#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 02:31:28 +0000 Message-ID: <87tx2i9vun.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Stefan Monnier writes: > Sounds nice. Do you imagine it as a replacement for the existing > scroll-up/down functions? Or rather (at least at first) as a separate > package? > Also, if something's missing for st-height to get more accurate > measurements, I suggest you make it a bug report asking for that missing > info/feature. I was mostly thinking the first. The only potentially downside I can think of is that it might be slower -- then again I'm just measuring line-heights, and of these there is (at most) only one line that won't eventually be displayed. If it were to remain mostly elisp, it would need a reliable way to measure the height of a line (essentially a `st-height' replacement), irrespective of whether it's displayed. It has also proven rather difficult to set the window start "absolutely". I've documented my findings in `st-move'. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 10:14:48 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 15:14:48 +0000 Received: from localhost ([127.0.0.1]:46244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkwrg-00062q-7l for submit@debbugs.gnu.org; Sun, 02 Nov 2014 10:14:48 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:40682) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkwrd-00062Z-5X for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 10:14:45 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NEF00C003IH2700@a-mtaout23.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 17:14:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00BY83OEYX50@a-mtaout23.012.net.il>; Sun, 02 Nov 2014 17:14:39 +0200 (IST) Date: Sun, 02 Nov 2014 17:14:26 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87wq7e9zcn.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof Message-id: <83a949y6r1.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: E Sabof > Date: Sun, 02 Nov 2014 01:15:52 +0000 > > I've made a prototype for an alternative way to scroll. Essentially scrolling > is done pixelwise irrespective of content. Whole lines are scrolled "normally", > and the remainder is vscrolled. If the end result is close to a line boundary > it gets "snapped" to it. > This prevents unpleasant jumping when encountering an image. It doesn't handle > the "image taller than window" case, but it would if `st-height' could measure > more accurately. Thanks. 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? Allow me a few comments about the code below. > (defvar st-ov nil) Is this overlay used anywhere? I couldn't find that. > (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. > (when (cl-plusp ws) Why not use '(> ws 0)' instead? It's marginally faster, I think. > (cl-incf ammount vscroll) Why not use '(setq amount (+ amount vscroll))' instead? It should be marginally faster. > (when (cl-minusp direction) Same question as for cl-plusp above. > (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? Also, if you do need the loop, why is it a good idea to use cl-reduce here, rather than keeping track of the running sum -- isn't the latter faster? (And I don't think you need to keep the 'rows' list, see below.) > (cl-defun st-move (lines vscroll) > ;; vscroll changes aren't always displayed. Haven't found a work-around for this. A recipe to reproduce this problem, perhaps as a separate bug report, would be nice. > ( line-info (st-get-lines pixels-to-move)) > ( heights (cadr line-info)) > ( initial-vscroll (car line-info)) > excess > enough-or-too-many-heights > too-few-heights) > (cl-incf pixels-to-move initial-vscroll) > (setq enough-or-too-many-heights (cl-reduce '+ heights) It looks like you never need the info about the height of the individual lines, only their sum. So perhaps st-get-lines shouldn't return the height info as a list, but as just one number? > too-few-heights (cl-reduce '+ (butlast heights) :initial-value 0) OK, 2 numbers. > ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick 10))) > ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick -10))) This doesn't support the equivalent of a nil argument, which means move by "near full screen". From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 10:16:48 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 15:16:48 +0000 Received: from localhost ([127.0.0.1]:46248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkwtb-00066O-TV for submit@debbugs.gnu.org; Sun, 02 Nov 2014 10:16:48 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:57574) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkwtZ-000668-LA for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 10:16:46 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEF00C003P4HC00@a-mtaout22.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 17:16:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00C1W3RNAJ40@a-mtaout22.012.net.il>; Sun, 02 Nov 2014 17:16:36 +0200 (IST) Date: Sun, 02 Nov 2014 17:16:23 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87tx2i9vun.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof Message-id: <838ujty6ns.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87tx2i9vun.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: E Sabof > Date: Sun, 02 Nov 2014 02:31:28 +0000 > > > Sounds nice. Do you imagine it as a replacement for the existing > > scroll-up/down functions? Or rather (at least at first) as a separate > > package? > > Also, if something's missing for st-height to get more accurate > > measurements, I suggest you make it a bug report asking for that missing > > info/feature. > > I was mostly thinking the first. If this is intended as a replacement for the existing functionality, then it needs to support all the features that the current code supports. The list of those features should include at least the following: . the argument to the commands can be nil, which means "almost the full window", where "almost full" depends on the value of next-screen-context-lines . the auto-window-vscroll variable . the scroll-preserve-screen-position option . signal an error at beginning and end of buffer, subject to the value of scroll-error-top-bottom . don't let point enter the scroll margin as result of scrolling . the window's old_point marker needs to be set after scrolling There's also a bug when scrolling near the end of buffer: the result is that the cursor us shown on a line beyond EOB, which should never happen. > The only potentially downside I can think of > is that it might be slower -- then again I'm just measuring line-heights, and > of these there is (at most) only one line that won't eventually be displayed. It is indeed much slower. I timed it on xdisp.c using Dmitry's scroll-up-benchmark function, and found this code to be 3 times slower than the current implementation. Turning off font-lock slashes about 40% of the benchmark time, so CC mode fontifications are not the main reason for the slowdown. If I compare the existing implementation with this one on xdisp.c with font-lock-mode turned off in both cases, this implementation is 16 times slower than what we have now. For the record, my timings are from an unoptimized build of a recent trunk, with your code byte-compiled. The general algorithm seems to be the same as in the current C implementation, so I doubt an ELisp implementation could match what we have in speed, let alone be faster. Now, I personally don't regard the scrolling command as something that needs to be lightning-fast (although others obviously do, see the on-going discussions on emacs-devel about that). But in this case, a single PageDown keypress takes close to a second to execute, which is slow enough to annoy. By contrast, the current implementation is almost instantaneous. (Again, this is in an unoptimized build; an optimized build should be about twice faster, but I think 0.4 sec for a single scroll might still annoy.) Finally, it looks like this code forces Emacs to display every single screen it scrolls through, even when it cannot keep up. I guess that's due to the 'redisplay' calls. This makes the situation where someone leans on the PageDown key and then releases it very unpleasant: Emacs keeps scrolling for a long time, and I didn't find a way of interrupting that. > If it were to remain mostly elisp, it would need a reliable way to measure the > height of a line (essentially a `st-height' replacement), irrespective of > whether it's displayed. Did you try to use pos-visible-in-window-p? AFAIU, it gives you what you want, including for lines that are taller than the window. > It has also proven rather difficult to set the window > start "absolutely". I've documented my findings in `st-move'. Does this happen only when point is on an image? (The comments in st-move seem to talk only about this situation.) If so, could you show a simple test case to demonstrate the problem? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 10:56:23 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 15:56:23 +0000 Received: from localhost ([127.0.0.1]:46265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkxVv-0007B2-KZ for submit@debbugs.gnu.org; Sun, 02 Nov 2014 10:56:23 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:35144) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkxVt-0007Ai-CE for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 10:56:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBYtkpjyBb4QWH4J6AQEB X-IPAS-Result: Au4MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBYtkpjyBb4QWH4J6AQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95794093" Received: from 69-165-143-59.dsl.teksavvy.com (HELO ceviche.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2014 10:56:15 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 3D88466108; Sun, 2 Nov 2014 10:56:15 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model Message-ID: References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> Date: Sun, 02 Nov 2014 10:56:15 -0500 In-Reply-To: <83a949y6r1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 02 Nov 2014 17:14:26 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org, E Sabof X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> (cl-incf ammount vscroll) > Why not use '(setq amount (+ amount vscroll))' instead? It should be > marginally faster. No, it's identical: (macroexpand '(cl-incf ammount vscroll)) => (setq ammount (+ ammount vscroll)) > why is it a good idea to use cl-reduce here, Because it's a lot more concise. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 11:06:30 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 16:06:30 +0000 Received: from localhost ([127.0.0.1]:46269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkxfh-0007SE-JT for submit@debbugs.gnu.org; Sun, 02 Nov 2014 11:06:29 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:34551) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkxfe-0007Rz-Hq for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 11:06:27 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEF00C005SIVU00@a-mtaout22.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 18:06:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00CD562JWH00@a-mtaout22.012.net.il>; Sun, 02 Nov 2014 18:06:20 +0200 (IST) Date: Sun, 02 Nov 2014 18:06:07 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <834muhy4cw.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org, esabof@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: E Sabof , 18923@debbugs.gnu.org > Date: Sun, 02 Nov 2014 10:56:15 -0500 > > > why is it a good idea to use cl-reduce here, > > Because it's a lot more concise. But it causes the loop to repeatedly sum the same numbers, no? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 11:21:33 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 16:21:33 +0000 Received: from localhost ([127.0.0.1]:46274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkxuH-0007pw-92 for submit@debbugs.gnu.org; Sun, 02 Nov 2014 11:21:33 -0500 Received: from mail-wg0-f42.google.com ([74.125.82.42]:35514) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkxuF-0007pf-2s for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 11:21:31 -0500 Received: by mail-wg0-f42.google.com with SMTP id k14so10926427wgh.1 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 08:21:25 -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=9288Aq2a9D1Ng0d8NlFCoz+zZPlPrNNGKCI4MyFu3J8=; b=BiLsLfXXaC3QJNSnNAGYNhbbHwpLE+40jnKVORgVvL9AbKOPEwareb5p3dGx3CJShP 71PKJozvOqrTDY/VGd+jxg3sy2hi116OTgg/bm+4ndqlbeisQgwzwBF7VePfz9Y+0Ph2 zAfue344ucJ25c/LleWK1Ihzr9lW1YfrTqN0W9rrDo6cS0qj4FlHkhTjYoOOR/I68WJw +PY4fBUKRVLcvPH/9UGgBgVO8Bh3YIN2Tz9RtY1FtN1lE5QJ9v4r9Zu/wRoB1execcbd TIYf/U87tDaBNC6T5itsNSoCeHpzmPw7wWsk1EiB+FAulZgET0Mlfn2TRALR9RQqeWKU +KbA== X-Received: by 10.194.87.131 with SMTP id ay3mr18387986wjb.66.1414945285312; Sun, 02 Nov 2014 08:21:25 -0800 (PST) Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id j8sm5676502wib.10.2014.11.02.08.21.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 08:21:24 -0800 (PST) References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> From: E Sabof To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <83a949y6r1.fsf@gnu.org> Date: Sun, 02 Nov 2014 16:21:23 +0000 Message-ID: <87r3xla7zw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > Thanks. > > 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 > Allow me a few comments about the code below. > >> (defvar st-ov nil) > > Is this overlay used anywhere? I couldn't find that. Developement left-over. >> (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. A more descriptive name for the function would be `st-get-pixel-height-of-line-at-point'. >> (when (cl-plusp ws) > > Why not use '(> ws 0)' instead? It's marginally faster, I think. > >> (cl-incf ammount vscroll) > > Why not use '(setq amount (+ amount vscroll))' instead? It should be > marginally faster. > >> (when (cl-minusp direction) > > Same question as for cl-plusp above. I just find infix comparisons somewhat uncomfortable. I can change them for a final implementation. >> (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. > Also, if you do need the loop, why is it a good idea to use cl-reduce > here, rather than keeping track of the running sum -- isn't the latter > faster? (And I don't think you need to keep the 'rows' list, see > below.) I really just wanted something working. And as you suggested below, values for enough-or-too-many-heights, too-few-heights, and probably the number of heights scanned would be sufficient. >> (cl-defun st-move (lines vscroll) >> ;; vscroll changes aren't always displayed. Haven't found a work-around for this. > > A recipe to reproduce this problem, perhaps as a separate bug report, > would be nice. > >> ( line-info (st-get-lines pixels-to-move)) >> ( heights (cadr line-info)) >> ( initial-vscroll (car line-info)) >> excess >> enough-or-too-many-heights >> too-few-heights) > >> (cl-incf pixels-to-move initial-vscroll) > >> (setq enough-or-too-many-heights (cl-reduce '+ heights) > > It looks like you never need the info about the height of the > individual lines, only their sum. So perhaps st-get-lines shouldn't > return the height info as a list, but as just one number? > >> too-few-heights (cl-reduce '+ (butlast heights) :initial-value 0) > > OK, 2 numbers. > >> ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick 10))) >> ;; (global-set-key (kbd "") (lambda () (interactive) (scroll-tick -10))) > > 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. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 11:31:51 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 16:31:51 +0000 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 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 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) 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) Date: Sun, 02 Nov 2014 18:31:08 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87r3xla7zw.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof Message-id: <8338a1y377.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 12:43:47 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 17:43:47 +0000 Received: from localhost ([127.0.0.1]:46308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzBq-0001WG-UW for submit@debbugs.gnu.org; Sun, 02 Nov 2014 12:43:47 -0500 Received: from mail-wg0-f46.google.com ([74.125.82.46]:50797) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzBo-0001W1-PU for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 12:43:45 -0500 Received: by mail-wg0-f46.google.com with SMTP id x13so9646454wgg.33 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 09:43:38 -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=bYS570wreN0Wv0fEvYIfflSSWHmAsS3GLOS/db7jE14=; b=TCkak+uCiNwOweHHFSJYddeiyvO5K8cJZvQajAxwXWR/8gx0LmOKynra4hcegYrWA/ y2YyZK0OgVNYKMFRJHj4CS96d3zU83aNAIN4TStLrakVfJ+RKbkWm/UW/+Vt6vj2cHSW Z0VN3Tq6K5uPD5xCMeHkcqW9JL7+TZHlyuQ92l8V8wkJR45DxrZA/+fB9lfC6WJx3uas qza91MlEMNy8/JApEx3l8CShRQozCRziBz2tChESucpfmV2VvZeAwq8ryoycJ9RSCUKn +6udmlHVF32nTru2z1Te2whCRbBWDqVAN0JGHZkZ+tNe4A49yeuVOfnj6IvyjrtTdYOI SoYQ== X-Received: by 10.180.182.195 with SMTP id eg3mr11051473wic.31.1414950218722; Sun, 02 Nov 2014 09:43:38 -0800 (PST) Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id l4sm15944192wjx.14.2014.11.02.09.43.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 09:43:37 -0800 (PST) References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> <8338a1y377.fsf@gnu.org> From: E Sabof To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <8338a1y377.fsf@gnu.org> Date: Sun, 02 Nov 2014 17:43:35 +0000 Message-ID: <87ppd5a46w.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > 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. 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". >> >> (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. >> 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. window-body-height can be very wrong if a large image is displayed in the buffer. Still some heuristics could be used to speed-up the most common case, all lines being ~= (default-line-height). >> > 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. 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. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 13:22:41 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 18:22:41 +0000 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 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 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) 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) Date: Sun, 02 Nov 2014 20:22:18 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87ppd5a46w.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 13:25:42 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 18:25:42 +0000 Received: from localhost ([127.0.0.1]:46356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzqO-0002eS-Rb for submit@debbugs.gnu.org; Sun, 02 Nov 2014 13:25:41 -0500 Received: from mail-wi0-f179.google.com ([209.85.212.179]:42264) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzqK-0002eB-EZ for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 13:25:37 -0500 Received: by mail-wi0-f179.google.com with SMTP id h11so4765838wiw.0 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 10:25:30 -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=O3AK/30TnU0ciJn3ECurNGEK21ZOZ+gCUJjMDwPdLm4=; b=O4cBtdsFrkfUS1PFb0jRit+rY1ABTKa0uTR4o7e34YTMXMdpMAvA5E3BMjY2uqM00p P75lAgMiRgDXcQEhjUp8HmnGL708Iq1qfS1qYmSKdRb2hIuZ3OSi5Y51KxOzgnUR9xn6 bHsYOpKGzJ0uCxr88SNVvVBO7TYOjC1i5HIlDnzOH1NVYiP7PvDXu5VaRBtdkyu+CArR jqzAzX/2FZeqJxRzvnuLmr7/jQJdWMaa+DCdpwf2DiDMoL0hAGYb5k+czQaAy4d92z+9 HmqKgnW/RX7K//5A4qO/6zoXWohMLFf80DCdhI4qemkbJDNAZYTC6hmcecwlYzLf6tkF qlpA== X-Received: by 10.194.110.4 with SMTP id hw4mr4050841wjb.102.1414952730707; Sun, 02 Nov 2014 10:25:30 -0800 (PST) Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id fr6sm6046021wic.1.2014.11.02.10.25.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 10:25:30 -0800 (PST) References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87tx2i9vun.fsf@gmail.com> <838ujty6ns.fsf@gnu.org> From: E Sabof To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <838ujty6ns.fsf@gnu.org> Date: Sun, 02 Nov 2014 18:25:28 +0000 Message-ID: <87oaspa293.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> From: E Sabof >> Date: Sun, 02 Nov 2014 02:31:28 +0000 >> >> > Sounds nice. Do you imagine it as a replacement for the existing >> > scroll-up/down functions? Or rather (at least at first) as a separate >> > package? >> > Also, if something's missing for st-height to get more accurate >> > measurements, I suggest you make it a bug report asking for that missing >> > info/feature. >> >> I was mostly thinking the first. > > If this is intended as a replacement for the existing functionality, > then it needs to support all the features that the current code > supports. The list of those features should include at least the > following: > > . the argument to the commands can be nil, which means "almost the > full window", where "almost full" depends on the value of > next-screen-context-lines Easy to implement naively, and heuristics should probably be considered. > . the auto-window-vscroll variable I think the variable would no longer be useful with this approach. > . the scroll-preserve-screen-position option Ideally I'd measure the pixel distance from the top and try to restore it, but alternatives can be considered if this affects performance. > . signal an error at beginning and end of buffer, subject to the > value of scroll-error-top-bottom I think I already have the code that determines this case, I just need to throw errors. > . don't let point enter the scroll margin as result of scrolling > > . the window's old_point marker needs to be set after scrolling I don't fully understand these, but they don't seem too complicated. > There's also a bug when scrolling near the end of buffer: the result > is that the cursor us shown on a line beyond EOB, which should never > happen. I've noticed this. The point flashes at a wrong position, and then goes back to "legal" position. I thought this was a display engine bug. >> The only potentially downside I can think of >> is that it might be slower -- then again I'm just measuring line-heights, and >> of these there is (at most) only one line that won't eventually be displayed. > > It is indeed much slower. I timed it on xdisp.c using Dmitry's > scroll-up-benchmark function, and found this code to be 3 times slower > than the current implementation. Turning off font-lock slashes about > 40% of the benchmark time, so CC mode fontifications are not the main > reason for the slowdown. If I compare the existing implementation > with this one on xdisp.c with font-lock-mode turned off in both cases, > this implementation is 16 times slower than what we have now. > > For the record, my timings are from an unoptimized build of a recent > trunk, with your code byte-compiled. > > The general algorithm seems to be the same as in the current C > implementation, so I doubt an ELisp implementation could match what we > have in speed, let alone be faster. > > Now, I personally don't regard the scrolling command as something that > needs to be lightning-fast (although others obviously do, see the > on-going discussions on emacs-devel about that). But in this case, a > single PageDown keypress takes close to a second to execute, which is > slow enough to annoy. By contrast, the current implementation is > almost instantaneous. (Again, this is in an unoptimized build; an > optimized build should be about twice faster, but I think 0.4 sec for > a single scroll might still annoy.) I'm aware of some inefficiencies in my code. My guess probably doesn't mean much, but maybe something along 2X could be achieved. > Finally, it looks like this code forces Emacs to display every single > screen it scrolls through, even when it cannot keep up. I guess > that's due to the 'redisplay' calls. This makes the situation where > someone leans on the PageDown key and then releases it very > unpleasant: Emacs keeps scrolling for a long time, and I didn't find a > way of interrupting that. st-move probably shouldn't call (redisplay) at all. I'll see if I can convert my comments to reproducible bugs. >> If it were to remain mostly elisp, it would need a reliable way to measure the >> height of a line (essentially a `st-height' replacement), irrespective of >> whether it's displayed. > > Did you try to use pos-visible-in-window-p? AFAIU, it gives you what > you want, including for lines that are taller than the window. > >> It has also proven rather difficult to set the window >> start "absolutely". I've documented my findings in `st-move'. > > Does this happen only when point is on an image? (The comments in > st-move seem to talk only about this situation.) If so, could you > show a simple test case to demonstrate the problem? I think there are ~3 different bugs involved (vscroll not being displayed, vscroll being nullified, and the point-on-image cases). I'll see if I can describe them better. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 13:36:21 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 18:36:21 +0000 Received: from localhost ([127.0.0.1]:46360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl00i-0002w3-Vy for submit@debbugs.gnu.org; Sun, 02 Nov 2014 13:36:21 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:37531) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl00g-0002vn-V5 for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 13:36:20 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NEF00I00CRS2300@a-mtaout20.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 20:36:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00HNZD0CK790@a-mtaout20.012.net.il>; Sun, 02 Nov 2014 20:36:12 +0200 (IST) Date: Sun, 02 Nov 2014 20:36:00 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87oaspa293.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof Message-id: <83zjc9wiun.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87tx2i9vun.fsf@gmail.com> <838ujty6ns.fsf@gnu.org> <87oaspa293.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: E Sabof > Cc: 18923@debbugs.gnu.org > Date: Sun, 02 Nov 2014 18:25:28 +0000 > > > . the auto-window-vscroll variable > > I think the variable would no longer be useful with this approach. In that case, we should deprecate it. I see it being used at least in Gnus. > > There's also a bug when scrolling near the end of buffer: the result > > is that the cursor us shown on a line beyond EOB, which should never > > happen. > > I've noticed this. The point flashes at a wrong position, and then goes > back to "legal" position. It doesn't go back on my system, unless I move point in some way. > I thought this was a display engine bug. It could be that. > I'm aware of some inefficiencies in my code. My guess probably doesn't > mean much, but maybe something along 2X could be achieved. Speeding up twice might be all we need to get a reasonably fast implementation. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 14:09:30 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 19:09:30 +0000 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 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 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) 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) 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> From: E Sabof To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <831tplxy1x.fsf@gnu.org> Date: Sun, 02 Nov 2014 19:09:20 +0000 Message-ID: <87mw89a07z.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 14:29:54 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 19:29:54 +0000 Received: from localhost ([127.0.0.1]:46392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl0qX-0004ML-Kp for submit@debbugs.gnu.org; Sun, 02 Nov 2014 14:29:53 -0500 Received: from mtaout27.012.net.il ([80.179.55.183]:53059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl0qU-0004M4-Jw for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 14:29:51 -0500 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NEF00100ET2ZU00@mtaout27.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 21:24:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF002CPF9DKJ10@mtaout27.012.net.il>; Sun, 02 Nov 2014 21:24:49 +0200 (IST) Date: Sun, 02 Nov 2014 21:29:32 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <87mw89a07z.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: E Sabof Message-id: <83wq7dwgdf.fsf@gnu.org> 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> <87mw89a07z.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: E Sabof > Cc: 18923@debbugs.gnu.org > Date: Sun, 02 Nov 2014 19:09:20 +0000 > > > 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). Tell me how to reproduce the exact problem you are talking about, and I will see if I understood the situation correctly. > > 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. IMO the most important case is when you need to scroll almost the full window, in which case the pixel size of the window is the main piece of information. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 18:11:06 2014 Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 23:11:06 +0000 Received: from localhost ([127.0.0.1]:46511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl4Ib-00036u-Ma for submit@debbugs.gnu.org; Sun, 02 Nov 2014 18:11:06 -0500 Received: from mail-wg0-f51.google.com ([74.125.82.51]:64352) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl4IZ-00036M-AX for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 18:11:04 -0500 Received: by mail-wg0-f51.google.com with SMTP id l18so9855369wgh.24 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 15:10:57 -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=6txo3pvjKnJhyiZc1bgVrfywu1y837176vCwFj6FCl0=; b=wZRll8i97YB6Xk2pfg0JqRSc3jmmnYCEjLuaiToq6mIQWJM54Myr6NXaAE54ungOFx rWt2MG6PaP3yQMMXb2+eQ6Mn1nlKS1E41V6pEyXGqmzr3dArQ96AZ55WyB6Wmqc/JzfC 0gk6ynrMPhY6BAa1eZa+oiDdNE2ebEJCo6JbqBPFAzB+YIAnXGn5KIELXmMhBQ0ZMplZ eZ60z4X82NSNHiDXYOoQV5hWwFYJWy7/qnXnGVkD9cNfhwuVvm6UBdX5xsfXb1a3Qot4 4o3qwslFWiBxPpCUJMvxgMopTblK4USSbfV0QxR+Hz2TnB9CN6Xn555QiIKyLQjccXiu UT2A== X-Received: by 10.180.36.229 with SMTP id t5mr12135363wij.56.1414969857439; Sun, 02 Nov 2014 15:10:57 -0800 (PST) Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id f9sm19902987wjw.31.2014.11.02.15.10.55 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 15:10:56 -0800 (PST) References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87sii1ahy9.fsf@gmail.com> From: E Sabof To: Stefan Monnier Subject: Re: bug#18923: Alternative scrolling model In-reply-to: Date: Sun, 02 Nov 2014 23:10:56 +0000 Message-ID: <87lhnt9p1b.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Stefan Monnier writes: >> The results should be identical to scroll-up/scroll-down, unless >> non-standard line heights are encountered. This means that a) the code would >> often be "under" such complications, not needing to know about them > > AFAIK scroll-margin is handled directly by the scroll-up/down code (tho > in a partly redundant way, but I believe it's because if we let the > subsequent redisplay do the job, it doesn't work quite right in all > cases). > >> It's a bit of a bug fix, but ultimately I have no objections. Perhaps it >> would be easier to estimate the breaking potential once it's "ready". > > OTOH to really get a lot of exposure, the best is to just install it > into Emacs as a replacement ;-) > >>> Have you measured the kind of impact it might have on performance? >>> Obviously, we could/should reimplement some of those functions in C. >> Right now it's slower, but tolerably so. > > There are already cases where Emacs scrolling is perceived as too slow. > AFAIK in most such cases the problem is due to the font-lock speed, > which should be unaffected by your code, but I still think actual > measurements quantifying the slowdown will be important. > > BTW, have you looked at the C code of scroll-up/down at all? > I'm not familiar with it, but it does do pixelwise scrolling to some > extent as well (tho IIUC only for really tall lines such as those with > images), so I'm curious to know exactly how the two compare. I have tried different settings, but they haven't quite worked for me. But I definitely need to become familiar with the existing implementation. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 21:35:55 2014 Received: (at 18923) by debbugs.gnu.org; 3 Nov 2014 02:35:55 +0000 Received: from localhost ([127.0.0.1]:46544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl7Uo-0001Cs-QA for submit@debbugs.gnu.org; Sun, 02 Nov 2014 21:35:55 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46721) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl7Ul-0001CZ-1G for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 21:35:51 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIxALNBIUGA0kiEsJy3IBAQEBBgEBAQEekDBYB4RLBYtkpjyBb4QWH4E1gUUBAQE X-IPAS-Result: Au0MAOatTlRFpY87/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIxALNBIUGA0kiEsJy3IBAQEBBgEBAQEekDBYB4RLBYtkpjyBb4QWH4E1gUUBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95812979" Received: from 69-165-143-59.dsl.teksavvy.com (HELO ceviche.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2014 21:35:45 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 043B4660F3; Sun, 2 Nov 2014 21:35:44 -0500 (EST) From: Stefan Monnier To: E Sabof Subject: Re: bug#18923: Alternative scrolling model Message-ID: References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87sii1ahy9.fsf@gmail.com> <87lhnt9p1b.fsf@gmail.com> Date: Sun, 02 Nov 2014 21:35:44 -0500 In-Reply-To: <87lhnt9p1b.fsf@gmail.com> (E. Sabof's message of "Sun, 02 Nov 2014 23:10:56 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> BTW, have you looked at the C code of scroll-up/down at all? >> I'm not familiar with it, but it does do pixelwise scrolling to some >> extent as well (tho IIUC only for really tall lines such as those with >> images), so I'm curious to know exactly how the two compare. > I have tried different settings, but they haven't quite worked for me. > But I definitely need to become familiar with the existing > implementation. I don't think the behavior you're looking for can be obtained from the current C code, indeed, but maybe the needed changes are limited. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 02 22:45:50 2014 Received: (at 18923) by debbugs.gnu.org; 3 Nov 2014 03:45:50 +0000 Received: from localhost ([127.0.0.1]:46601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl8aT-00036H-LH for submit@debbugs.gnu.org; Sun, 02 Nov 2014 22:45:49 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:39643) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xl8aR-000361-AD for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 22:45:48 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEG00J0023Q1W00@a-mtaout22.012.net.il> for 18923@debbugs.gnu.org; Mon, 03 Nov 2014 05:45:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEG00JQ12G41P10@a-mtaout22.012.net.il>; Mon, 03 Nov 2014 05:45:41 +0200 (IST) Date: Mon, 03 Nov 2014 05:45:30 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <83wq7dwgdf.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: esabof@gmail.com Message-id: <83sii1vtet.fsf@gnu.org> 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> <87mw89a07z.fsf@gmail.com> <83wq7dwgdf.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 02 Nov 2014 21:29:32 +0200 > From: Eli Zaretskii > Cc: 18923@debbugs.gnu.org > > > > 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. > > IMO the most important case is when you need to scroll almost the full > window, in which case the pixel size of the window is the main piece > of information. In addition, you could change st-move to work in pixels instead of lines. Then you could use posn-at-x-y inside st-move to find the position at a given Y offset from the current window-start, and move the new window-start to that position. This should eliminate the need to use vertical-motion in st-move even if you need to scroll by one or a few screen lines. The conversion of the number of lines to pixels is straightforward using default-line-height. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 03 11:03:52 2014 Received: (at 18923) by debbugs.gnu.org; 3 Nov 2014 16:03:52 +0000 Received: from localhost ([127.0.0.1]:47735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlK6h-0002zB-Kk for submit@debbugs.gnu.org; Mon, 03 Nov 2014 11:03:51 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:37310) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlK6e-0002yw-C4 for 18923@debbugs.gnu.org; Mon, 03 Nov 2014 11:03:49 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NEH00P000A80S00@mtaout26.012.net.il> for 18923@debbugs.gnu.org; Mon, 03 Nov 2014 18:02:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEH00HNS0JMMG80@mtaout26.012.net.il>; Mon, 03 Nov 2014 18:02:10 +0200 (IST) Date: Mon, 03 Nov 2014 18:03:32 +0200 From: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83r3xkw9t7.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87sii1ahy9.fsf@gmail.com> <87lhnt9p1b.fsf@gmail.com> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org, esabof@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Date: Sun, 02 Nov 2014 21:35:44 -0500 > Cc: 18923@debbugs.gnu.org > > >> BTW, have you looked at the C code of scroll-up/down at all? > >> I'm not familiar with it, but it does do pixelwise scrolling to some > >> extent as well (tho IIUC only for really tall lines such as those with > >> images), so I'm curious to know exactly how the two compare. > > I have tried different settings, but they haven't quite worked for me. > > But I definitely need to become familiar with the existing > > implementation. > > I don't think the behavior you're looking for can be obtained from the > current C code, indeed, but maybe the needed changes are limited. The current implementation only uses vscroll for partially visible screen lines (a.k.a. "glyph rows"). This is by design (and consistent with what line-move does), but we can decide to change that, if that's what people want. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 03 14:02:41 2014 Received: (at 18923) by debbugs.gnu.org; 3 Nov 2014 19:02:41 +0000 Received: from localhost ([127.0.0.1]:47831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlMtl-0007se-EB for submit@debbugs.gnu.org; Mon, 03 Nov 2014 14:02:41 -0500 Received: from mail-wi0-f177.google.com ([209.85.212.177]:51390) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlMtj-0007sW-LG for 18923@debbugs.gnu.org; Mon, 03 Nov 2014 14:02:40 -0500 Received: by mail-wi0-f177.google.com with SMTP id ex7so7312608wid.4 for <18923@debbugs.gnu.org>; Mon, 03 Nov 2014 11:02:38 -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=A/qg2sq1G75CUZ+3BPyZzt38jbqPCD7+3GlW1/MTCuE=; b=ruRBWm6+ca9MAFSdkJKtQybb3P5X06Lf5t9AcBSPFllEJhk7U8FWsQyNTygoSsE1pm 8dU9Vd0ExRyYY5LaMs/WvbVITH87HlNY1Yq4agpkIoyEsmmf9aWMcuIHxBtrD6uW7Bfd jLKKfwZGrueEqInWVXtkFvkXh/tFJHpS9CfO7J9/qbFRbXon3qk1ZmdtLe8+25LdQHu/ UNPNd4kbuU2gMkLEp40EJ5CqdzDucVGo0oOtfgyy92nNH869KJTtX61KAVvAuDjZHq3w yUKfPeY1fqaPWxMd4hZxMlNHI8YufrjUHknXFP+Q9e1vVQbwOcmg03jVJk1gTCEatjs+ 2Hdw== X-Received: by 10.180.149.242 with SMTP id ud18mr18146361wib.58.1415041358743; Mon, 03 Nov 2014 11:02:38 -0800 (PST) Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id fx2sm23133074wjb.37.2014.11.03.11.02.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 11:02:35 -0800 (PST) References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87sii1ahy9.fsf@gmail.com> <87lhnt9p1b.fsf@gmail.com> <83r3xkw9t7.fsf@gnu.org> From: E Sabof To: Eli Zaretskii Subject: Re: bug#18923: Alternative scrolling model In-reply-to: <83r3xkw9t7.fsf@gnu.org> Date: Mon, 03 Nov 2014 19:02:35 +0000 Message-ID: <87k33c9kfo.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > The current implementation only uses vscroll for partially visible > screen lines (a.k.a. "glyph rows"). This is by design (and consistent > with what line-move does), but we can decide to change that, if that's > what people want. Potentially I could try calling Lisp functions from window_scroll_pixel_based, until everything seemed to work. At which point the additional Lisp could be translated to C. Evgeni From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 04 04:14:21 2019 Received: (at 18923) by debbugs.gnu.org; 4 Nov 2019 09:14:21 +0000 Received: from localhost ([127.0.0.1]:35848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRYRJ-0000Dr-94 for submit@debbugs.gnu.org; Mon, 04 Nov 2019 04:14:21 -0500 Received: from host.gofardesign.uk ([208.79.239.190]:56709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRYRH-0000DS-E3 for 18923@debbugs.gnu.org; Mon, 04 Nov 2019 04:14:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marxist.se; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lqCyf9roW+FAGWan9YLDxLfQHwWr6dlKSbV14UdB5B4=; b=gBdYsanZbtAKI2ZqmNteqfqDNP SpmkqO++zBeuWfuKWtWrvwHtWMJXaopDl/hHt0SVkOXIHrIdJwNHYDWkFjyLju47ERaSWtlqdU9Yy bW/6GjU5LF2ec4ftBLO3aR7onYZpYlp9MUyO30/CEPq1lWqHSAl1mK7xHMMmGuYsFGVE=; Received: from h-70-69.a785.priv.bahnhof.se ([155.4.70.69]:53362 helo=localhost) by host.gofardesign.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iRYR9-0004P3-Vr; Mon, 04 Nov 2019 03:14:12 -0600 From: Stefan Kangas To: E Sabof Subject: Re: Alternative scrolling model In-Reply-To: <87wq7e9zcn.fsf@gmail.com> (E. Sabof's message of "Sun, 02 Nov 2014 01:15:52 +0000") References: <87wq7e9zcn.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Mon, 04 Nov 2019 10:14:09 +0100 Message-ID: <87pni8c8bi.fsf@marxist.se> MIME-Version: 1.0 Content-Type: text/plain X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.gofardesign.uk X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marxist.se X-Get-Message-Sender-Via: host.gofardesign.uk: authenticated_id: stefan@marxist.se X-Authenticated-Sender: host.gofardesign.uk: stefan@marxist.se X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) E Sabof writes: > I've made a prototype for an alternative way to scroll. Essentially > scrolling is done pixelwise irrespective of content. Whole lines are > scrolled "normally", and the remainder is vscrolled. If the end > result is close to a line boundary it gets "snapped" to it. > > This prevents unpleasant jumping when encountering an image. It > doesn't handle the "image taller than window" case, but it would if > `st-height' could measure more accurately. That was 5 years ago. Are you still working on this? Best regards, Stefan Kangas From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 08:16:42 2022 Received: (at 18923) by debbugs.gnu.org; 22 Apr 2022 12:16:42 +0000 Received: from localhost ([127.0.0.1]:51827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhsDK-0001Mj-9J for submit@debbugs.gnu.org; Fri, 22 Apr 2022 08:16:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhsDJ-0001HO-0s for 18923@debbugs.gnu.org; Fri, 22 Apr 2022 08:16:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hCUzcsK3mKNw1MJWbSCcD+LWr53Z48Es5BBBrYrxPKA=; b=ryJR9ft0Tq8P7Kr1lSuZpEz1eB FS46an1EeLiWeLlLpb4DWnWM3C0xuFD1swUSK5ldpeOQmEU6ZGsK15/M8aC3qJd6A5vWnS3/QLPtz hMKqKismG9Cf2gjiTDDMXDnWcMwKr/188vburOtcqwjcaALImS//65Vpwd1qhvN2HRlc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhsD9-0006DT-TW; Fri, 22 Apr 2022 14:16:34 +0200 From: Lars Ingebrigtsen To: E Sabof Subject: Re: bug#18923: Alternative scrolling model References: <87wq7e9zcn.fsf@gmail.com> X-Now-Playing: Feathered Sun's _How Strange_: "How Strange (Original Mix)" Date: Fri, 22 Apr 2022 14:16:31 +0200 In-Reply-To: <87wq7e9zcn.fsf@gmail.com> (E. Sabof's message of "Sun, 02 Nov 2014 01:15:52 +0000") Message-ID: <871qxp2u00.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: E Sabof writes: > I've made a prototype for an alternative way to scroll. Essentially > scrolling is done pixelwise irrespective of content. Whole lines are > scrolled "normally", and the remainder is vscrolled. If t [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18923 Cc: 18923@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) E Sabof writes: > I've made a prototype for an alternative way to scroll. Essentially > scrolling is done pixelwise irrespective of content. Whole lines are > scrolled "normally", and the remainder is vscrolled. If the end result > is close to a line boundary it gets "snapped" to it. > > This prevents unpleasant jumping when encountering an image. It > doesn't handle the "image taller than window" case, but it would if > `st-height' could measure more accurately. (I'm going through old bug reports that unfortunately weren't resolved at the time.) Skimming this thread, I think the proposed things here were basically implemented by Po Lu as `pixel-scroll-precision-mode' in Emacs 29, so I'm therefore closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 08:16:49 2022 Received: (at control) by debbugs.gnu.org; 22 Apr 2022 12:16:49 +0000 Received: from localhost ([127.0.0.1]:51830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhsDR-0001Sj-Hz for submit@debbugs.gnu.org; Fri, 22 Apr 2022 08:16:49 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhsDQ-0001NE-0v for control@debbugs.gnu.org; Fri, 22 Apr 2022 08:16:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=B3AjhtaOcPZ6WTdZYFDJ4k3u6Ny9joLXSJdkchVjmxQ=; b=dOoaPe975W+Df+Q6qMVIKWTMjP ytLMKsFbRU2kntBDH/wu0XARxizi3ZqQgQWv0DWLztpbH0TX9VSRtWezjaKLobglFd69YO/cjQgKx AoJsy/kGxBjFEWORtTZoBxMTM8Fe+rqkuhnmJOsuznoQH0znaVbL4SUg//8NcxrWmAgk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhsDI-0006Dc-Ek for control@debbugs.gnu.org; Fri, 22 Apr 2022 14:16:42 +0200 Date: Fri, 22 Apr 2022 14:16:36 +0200 Message-Id: <87zgkd1fff.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #18923 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 18923 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 18923 quit From unknown Mon Aug 18 02:31:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 21 May 2022 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator