GNU bug report logs - #18923
Alternative scrolling model

Previous Next

Full log

Message #29 received at 18923 <at> debbugs.gnu.org (full text, mbox):

From: E Sabof <esabof <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18923 <at> debbugs.gnu.org
Subject: Re: bug#18923: Alternative scrolling model
Date: Sun, 02 Nov 2014 17:43:35 +0000

Eli Zaretskii <eliz <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.