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

[Dani Moncayo]

>> >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.

IMO, `scroll-margin' clearly makes sense whenever the displayed text
changes, regardless of the relation between the old displayed text and
the new one.

>> > 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.
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMO, the current documentation describes the behavior that makes
sense, and the one I want to have.

>> 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.

It should.  In fact it does; the only exception I've found so far is
the one described in the initial post.

>> 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.

Well, then consider this bug report as a feature request.

>> 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.

Does that behavior (changing the location of the the current line
after minimizing + restoring the Emacs frame) makes sense to anyone?
Come on ...

Please Eli, reconsider this.  The meaning of `scroll-margin' makes
perfectly sense here.

Thanks

-- 
Dani Moncayo