bug#5718: scroll-margin in buffer with small line count.

[npostavs]

Andrew Hyatt <ahyatt@gmail.com> writes:

> Oleksandr Gavenko <gavenkoa@gmail.com> writes:
>
>> I have official Emacs 22.3 from FSF ftp server for Windows.
>>
>> When set
>>
>> (setq scroll-margin 4)
>>
>> in buffer with window width 6 lines real margin value is 1
>> (so real line scrolling done when press <up> on second line
>> or when press <down> on fifth line).
>>
>> Experiment show such dependence of real margin on line count:
>>
>> lines      real-scroll-margin
>> 3,4,5,6         1
>> 7,8,9,10        2
>> 11,12,13,14     3
>>>15             4
>>
>> I count from 3 as when try make less lines Emacs warn.
>>
>> I think that whose modify scroll-margin want to see as many
>> as possible margin value up to its customization value.
>>
>> This formula produce such values:
>>
>> best-scroll-margin = min( (line_count - 1)/2,  scroll-margin)
>>
>> So previous table changed to:
>>
>> lines      best-scroll-margin
>> 3,4             1
>> 5,6             2
>> 7,8             3
>>>9              4
>>
>> Also as you can see in proposal case
>> user switch start work from 9 lines in window, not 15!
>>
>> Please implement described behaviour.
>
> I'm having a hard time understanding this report.  However, it seems
> like more like a wishlist request than a bug: you want to change the
> scrolling behavior.  I'm going to change this to wishlist for now, but
> let me know if I've misunderstood, please.

I think the complaint is that the `scroll-margin' effective value is
capped at a 1/4 of the window height, as seen in this
window_scroll_pixel_based (window.c):

  this_scroll_margin = max (0, scroll_margin);
  this_scroll_margin
    = min (this_scroll_margin, window_total_lines / 4);

Whereas, it seems more logical to cap it at half window height.

I seem to recall another feature request that I can't find now about
always keeping the cursor in the middle of the window.  If this
restriction were loosened it might be possible to implement by setting
scroll-margin to a very high number.  There might well be some important
reason to divide by 4 though (I haven't looked at the following code).