bug#18923: Alternative scrolling model

[E Sabof]

Eli Zaretskii <eliz@gnu.org> 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 "<next>") (lambda () (interactive) (scroll-tick 10)))
>> ;; (global-set-key (kbd "<prior>") (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