bug#18923: Alternative scrolling model

[E Sabof]

Eli Zaretskii <eliz@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