bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

>> IMO, `scroll-margin' clearly makes sense whenever the displayed text
>> changes, regardless of the relation between the old displayed text and
>> the new one.
>
> I agree with Eli that this is a documentation bug. The very name
> "scroll-margin" clearly says that its effect is related to scrolling,
> and it's in fact so though the docstring might suggest otherwise. It's
> true that <backspace> in an Info buffer would be, from a user's POV, a
> "motion command", but not scrolling IMO.

What's the point of distinguishing "motion" and "scrolling" here?  IMO
someone who customizes `scroll-margin' is for having (always) some
context lines on both sides of the current line (but I'm repeating
myself).

> Do you also expect M-> M-< to
> move the point to the second line of the buffer, or to display a
> ghostly empty line above 1st line?

For M-> I expect to leave `scroll-margin' lines below the current (last) line.

M-< is an exception, because it makes little sense to show empty lines
before the first one.

IOW: The current behavior of those keys is the right one, IMO.

>> Does that behavior (changing the location of the the current line
>> after minimizing + restoring the Emacs frame) makes sense to anyone?
>> Come on ...
>
> On this one I agree with you. After minimize / restore, Emacs
> shouldn't recenter the point. But that's unrelated to scrolling; it's
> just that Emacs has a definite affinity for recentering whether the
> user wants or not.

Yes, recentering should not happen here, obviously.

>> Please Eli, reconsider this.  The meaning of `scroll-margin' makes
>> perfectly sense here.
>
> No, you want some new variable (and behavior) `point-margin' or somesuch.

I don't think a new variable is needed at all.  Just take care of
`scroll-margin' whenever Emacs decides where to put the current line
in the window; and that includes the case brought up in this report.

-- 
Dani Moncayo