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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 2 Dec 2012 22:51:44 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13055@debbugs.gnu.org
> 
> >From an user point of view, the <backspace> key (from Info buffers) is
> indeed a movement command.  In this case the movement was from the to
> of one info node to the bottom of another one (the previous one).

The crucial difference is that in your case there's nothing in common
between the two texts.  Scroll-related options are there to let you
control how much overlap is kept between successive windows of text.
When there's nothing in common, there can be no overlap, and therefore
these variables make no sense.

> > IOW, scroll-margin determines when automatic scrolling is triggered,
> > but not where point can be legitimately located in a window.
> 
> That makes little sense to me, and is not what I interpret from the
> documentation:
> 
>      The variable `scroll-margin' restricts how close point can come to
>   the top or bottom of a window (even if aggressive scrolling specifies a
>   fraction F that is larger than the window portion between the top and
>   the bottom margins).  Its value is a number of screen lines; if point
>   comes within that many lines of the top or bottom of the window, Emacs
>   performs automatic scrolling.  By default, `scroll-margin' is 0.

If the documentation leads you to different conclusions, it's
something that should be fixed in the documentation.  E.g.

      The variable `scroll-margin' restricts how close point can come to
   the top or bottom of a window as part of cursor motion commands.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> As I see it, this variable guarantees the users to _always_ see some
> context lines around point, which is an important feature to me.

No, it doesn't.

> Without this feature, I would be sometimes unsure about whether the
> current line is the one I am looking for (because I have no context
> lines below/above the current one).  That's the very reason I set this
> variable in my init file, and it makes no sense to me to honor this
> variable in some situations and not in others.

It was always that way in Emacs.  What you expect is a feature that
never existed.

> And BTW, one symptom of the abnormal location of the current line in
> my recipe is this: just after the last step, if you minimize the Emacs
> frame and restore it again, the current line is then centered in the
> window.  What sense does that make?  The current line should not
> change because of that, definitely.

I disagree, sorry.