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

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> 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);
>
> Which reveals a subtle bug: the actual scroll margin should be 1 for 7
> lines, 2 for 11, etc.  The problem is that the value of
> window_total_lines includes the mode line, which it shouldn't.  Maybe
> this should be fixed.

I was looking at fixing it, but I got confused by this comment in
window.h:

/* Height in pixels, and in lines, of the mode line.
   May be zero if W doesn't have a mode line.  */
#define WINDOW_MODE_LINE_HEIGHT(W)      \

How is the height "in pixels, and in lines"?  Doesn't it have to be one
or the other?

>
>> Whereas, it seems more logical to cap it at half window height.
>
> No, I think it would leave too few lines for moving the cursor.  This
> has been Emacs behavior since time immemoriam, so if we want to have a
> different behavior, it should be implemented an opt-in option, not the
> default.

Yes, sure.  This is about Emacs' behaviour after the user has customized
scroll-margin, so the default isn't in question anyway.  I imagine
something like this:

  DEFVAR_LISP ("minimum-non-scroll-lines", Vminimum_non_scroll_lines,
    doc: /* Lines around window's center where `scoll-margin' doesn't apply.
If point is within this many lines from the window's center, it will
not cause scrolling regardless of the value of `scroll-margin'.  If
this is a float then it represents a fraction of the current window's
lines.  */);
  Vminimum_non_scroll_lines = make_float (1.0/4.0);

And then setting this to 1 would make scroll-margin have the effect that
the OP expects.