bug#18923: Alternative scrolling model

[Eli Zaretskii <eliz@gnu.org>]

> From: E Sabof <esabof@gmail.com>
> 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.