From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: E Sabof Newsgroups: gmane.emacs.bugs Subject: bug#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 17:43:35 +0000 Message-ID: <87ppd5a46w.fsf@gmail.com> References: <87wq7e9zcn.fsf@gmail.com> <83a949y6r1.fsf@gnu.org> <87r3xla7zw.fsf@gmail.com> <8338a1y377.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414950266 32159 80.91.229.3 (2 Nov 2014 17:44:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 17:44:26 +0000 (UTC) Cc: 18923@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 18:44:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XkzCL-0005Bs-H0 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 18:44:17 +0100 Original-Received: from localhost ([::1]:58677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkzCL-000652-7Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 12:44:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkzCC-00064u-EQ for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 12:44:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XkzC6-0006gp-HY for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 12:44:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkzC6-0006gl-E2 for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 12:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XkzC6-0001Wt-8W for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 12:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: E Sabof Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Nov 2014 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18923-submit@debbugs.gnu.org id=B18923.14149502275849 (code B ref 18923); Sun, 02 Nov 2014 17:44:02 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 17:43:47 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <8338a1y377.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95388 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