bug#12811: 24.3.50; `scroll-up/down-aggressively' don't seem to work as expected

[Dani Moncayo]

>> So I'd like to make this request:
>> * Make obsolete the variables `scroll-up/down-aggressively'.
>> * Extend the semantics of the variable `scroll-step' to accept also a
>> fractional number between 0 and 1, so that for example 0.7 would mean:
>> "when point moves out, try to get it back into view by scrolling
>> up/down an amount equal to the 70% of the height of the window.  If
>> that fails, center in the window the line where point is".
>
> Wouldn't this keep the same semantics, but in one variable instead of
> 3?

Not exactly: The functionality behind `scroll-up/down-aggressively'
(as explained in the manual) make no sense in some cases (after doing
a "big jump"), and is similar in spirit to the functionality behind
`scroll-step' in the other cases (after doing a "small jump").

Hence my proposal, which aims to get rid of
`scroll-up/down-aggressively' and fulfill the small gap of
functionality derived from that removal. (see below)

> Anyway, it's too late to make such changes now, because a year and a
> half so ago, there a was similar discussion about
> scroll-conservatively, and people who set it to a large value
> explicitly asked for that to work over large scrolls.  So the code was
> restructured to support that (that's why it was so easy for me to fix
> this one);

I'm sorry, I fail to see how that is related to the issue at hand. :(

> going back means a serious surgery on that code, which I
> think is unjustified at this point, as I didn't hear any complaints
> about scrolling for a long time.

But I don't think my proposal would mean "going back", but the
opposite: make both the user interface and the program more simple and
coherent, because:
* We'll get rid of two variables (well, after a period of obsolescence).
* The change related to `scroll-step' should be pretty
straightforward, because the spirit of the variable would be
untouched: just in the case that the variable holds a floating point
value, the amount of lines to scroll should be computed based on that
value and the current window height.

>> It would not make sense, indeed, but according to the current
>> documentation, point should be positioned according to
>> `scroll-up/down-aggressively'.
>
> Well, now it does.

? I've not tested your fix yet, but if now the program behaves like
the documentation says, it will be good, but as we've agreed, that
behavior is undesirable in some cases (after a big jump).

>> > That is why what you expected never worked in Emacs, at least since
>> > v21.1.  The code which implements the effect of these variables was
>> > written under the assumption that point is only a small ways outside
>> > of the window, one or 2 screen lines, because this is what happens
>> > when you type "C-n" or "C-p" on the border of the scroll margin.
>>
>> But that assumption is false in many real-life cases.
>
> Not when you cause the scroll with C-n or C-p (without numeric
> arguments).  Then it's true.

Of course, but as I say, in many real-life cases (e.g. when doing
Isearch) the assumption is false, and so the resulting behavior is
undesirable.

>> > Having said that, since the code already almost did TRT, it is much
>> > easier for me to fix it for this use case than to argue about the
>> > applicability of these variables.  So I did just that in revision
>> > 110795 on the emacs-24 branch.
>>
>> Good, thanks.  Then perhaps the documentation should be updated to
>> reflect this, no?
>
> What's wrong with the documentation now?  The code does what it says,
> no?

Sorry I didn't get you right: I thought your change was about avoiding
that after a big jump the current line will be always centered.

-- 
Dani Moncayo