bug#18923: Alternative scrolling model

[E Sabof <esabof@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The results should be identical to scroll-up/scroll-down, unless
>> non-standard line heights are encountered.  This means that a) the code would
>> often be "under" such complications, not needing to know about them
>
> AFAIK scroll-margin is handled directly by the scroll-up/down code (tho
> in a partly redundant way, but I believe it's because if we let the
> subsequent redisplay do the job, it doesn't work quite right in all
> cases).
>
>> It's a bit of a bug fix, but ultimately I have no objections. Perhaps it
>> would be easier to estimate the breaking potential once it's "ready".
>
> OTOH to really get a lot of exposure, the best is to just install it
> into Emacs as a replacement ;-)
>
>>> Have you measured the kind of impact it might have on performance?
>>> Obviously, we could/should reimplement some of those functions in C.
>> Right now it's slower, but tolerably so.
>
> There are already cases where Emacs scrolling is perceived as too slow.
> AFAIK in most such cases the problem is due to the font-lock speed,
> which should be unaffected by your code, but I still think actual
> measurements quantifying the slowdown will be important.
>
> BTW, have you looked at the C code of scroll-up/down at all?
> I'm not familiar with it, but it does do pixelwise scrolling to some
> extent as well (tho IIUC only for really tall lines such as those with
> images), so I'm curious to know exactly how the two compare.

I have tried different settings, but they haven't quite worked for me.
But I definitely need to become familiar with the existing
implementation.

Evgeni