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

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

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

Maybe I'm missing something, but after reading (info "(emacs) Auto
Scrolling") and the docstrings of the variables
`scroll-up/down-aggressively', the behavior I observe after playing a
bit doesn't seem right to me.

Recipe from "emacs -Q":
1. Visit the attached file.
2. Adjust the height of the Emacs GUI frame so that only lines 1 to 11
are visible.  With this setup it is easy to tell the relative position
of a line in the window in terms of percentage from the top or bottom,
since each line counts as 10% for such percentages.
3. Go to line 1.
4. Type: C-u 1 5 C-n
--> Point goes to line 16, and that line is centered in the window. So
everything is as expected so far.
5. M-: (setq scroll-up-aggressively 0.7) <RET>
6. Repeat steps #3 and #4.
--> This time I observe that point goes to line 16, but that line is
near the bottom of the window (9th line; 20% from the bottom) when it
should be near the top (4th line; 70% from the bottom).


I also observe a misbehavior when testing scroll-down-aggressively:
1. M-: (setq scroll-down-aggressively 0.7) <RET>
2. Go to line 30 and make that line the last visible one.
3. Type: C-u 1 1 C-p
--> I observe that point goes to line 19, but that line is the 10th in
the window (90% from the top), when it should be the 8th line (70%
from the top).


In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-11-05 on MS-W7-DANI
Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src
 -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5
 -I../../libs/giflib-4.1.4-1-lib/include
 -I../../libs/jpeg-6b-4-lib/include
 -I../../libs/tiff-3.8.2-1-lib/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.9-w32-bin/include
 -I../../libs/libiconv-1.9.2-1-lib/include'

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


-- 
Dani Moncayo

[-- Attachment #2: test.txt --]
[-- Type: text/plain, Size: 111 bytes --]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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

[Eli Zaretskii]

> Date: Tue, 6 Nov 2012 00:27:55 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> 1. Visit the attached file.
> 2. Adjust the height of the Emacs GUI frame so that only lines 1 to 11
> are visible.  With this setup it is easy to tell the relative position
> of a line in the window in terms of percentage from the top or bottom,
> since each line counts as 10% for such percentages.

I guess you meant lines 1 to 10, not 11, because with 10 the
percentages are not integral numbers of lines.

> 3. Go to line 1.
> 4. Type: C-u 1 5 C-n
> --> Point goes to line 16, and that line is centered in the window. So
> everything is as expected so far.
> 5. M-: (setq scroll-up-aggressively 0.7) <RET>
> 6. Repeat steps #3 and #4.
> --> This time I observe that point goes to line 16, but that line is
> near the bottom of the window (9th line; 20% from the bottom) when it
> should be near the top (4th line; 70% from the bottom).
> 
> 
> I also observe a misbehavior when testing scroll-down-aggressively:
> 1. M-: (setq scroll-down-aggressively 0.7) <RET>
> 2. Go to line 30 and make that line the last visible one.
> 3. Type: C-u 1 1 C-p
> --> I observe that point goes to line 19, but that line is the 10th in
> the window (90% from the top), when it should be the 8th line (70%
> from the top).

IMO, it doesn't make sense to expect scroll-up/down-aggressively do
anything useful when you move point by more than a window-full.  (In
your case, the window is 11 (or 10) lines, and you move point by 15
lines.)  These variables exist to control the _overlap_ between the
current window-full of text and the next/previous one.  When you move
by more than the window's height, so that there's no overlap at all,
these variables are meaningless.  E.g., what would you expect them to
do with "C-u 100 C-n", or with "C-u 100000 M-x goto-char"? why would
it make sense to position point anywhere but the middle of the window
for such large scrolls?

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.

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.  Just don't ask me to make C-v and M-v
also obey these variables...

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

[Eli Zaretskii]

> Date: Tue, 06 Nov 2012 18:54:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12811@debbugs.gnu.org
> 
> > Date: Tue, 6 Nov 2012 00:27:55 +0100
> > From: Dani Moncayo <dmoncayo@gmail.com>
> > 
> > 1. Visit the attached file.
> > 2. Adjust the height of the Emacs GUI frame so that only lines 1 to 11
> > are visible.  With this setup it is easy to tell the relative position
> > of a line in the window in terms of percentage from the top or bottom,
> > since each line counts as 10% for such percentages.
> 
> I guess you meant lines 1 to 10, not 11, because with 10 the
> percentages are not integral numbers of lines.   ^^^^^^^

"with 11", of course.

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

[Dani Moncayo]

>> 1. Visit the attached file.
>> 2. Adjust the height of the Emacs GUI frame so that only lines 1 to 11
>> are visible.  With this setup it is easy to tell the relative position
>> of a line in the window in terms of percentage from the top or bottom,
>> since each line counts as 10% for such percentages.
>
> I guess you meant lines 1 to 10, not 11, because with 11 the
> percentages are not integral numbers of lines.

Actually I meant lines 1 to 11, because that way:
* Line 1 is 0% from the top of the window and 100% from the bottom.
* Line 11 is 0% from the bottom of the window and 100% from the top.
* Line 6 is 50% from the top and bottom of the window (i.e. the middle line).
* In general, Line N is 10(N-1)% from the top of the window and
10(11-N)% from the bottom (i.e., each like counts as 10% for these
percentages).

> IMO, it doesn't make sense to expect scroll-up/down-aggressively do
> anything useful when you move point by more than a window-full.  (In
> your case, the window is 11 (or 10) lines, and you move point by 15
> lines.)  These variables exist to control the _overlap_ between the
> current window-full of text and the next/previous one.  When you move
> by more than the window's height, so that there's no overlap at all,
> these variables are meaningless.

Good point.  I agree with you, of course.  I also thought about that
before submitting the bug report, but decided to stick (for the
moment) to the discrepancy I saw between the documentation and the
program's behavior.

The more I think about these two variables, the less they make sense
to me, and the less I like the approach behind them, which is
misguided, IMO.

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

>  E.g., what would you expect them to
> do with "C-u 100 C-n", or with "C-u 100000 M-x goto-char"? why would
> it make sense to position point anywhere but the middle of the window
> for such large scrolls?

It would not make sense, indeed, but according to the current
documentation, point should be positioned according to
`scroll-up/down-aggressively'.  Yes, that makes no sense.

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

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

> Just don't ask me to make C-v and M-v
> also obey these variables...

Of course I won't :).  IMO C-v and M-v should always show the
next/previous page, regardless of the "auto scrolling" control
variables.

Thanks again, and please, consider the proposal I've made before.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Tue, 6 Nov 2012 20:18:30 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12811@debbugs.gnu.org
> 
> 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?

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

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

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

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

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

[Juanma Barranquero]

On Tue, Nov 6, 2012 at 10:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:

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

As a prominent and vocal member of the
scroll-conservatively-set-to-a-large-value clique, yes, please, let's
avoid making unnecessary changes to scrolling. :-)

    Juanma

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

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

[Dani Moncayo]

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

Replace "avoiding" with "ensure".  Sorry

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Wed, 7 Nov 2012 10:23:52 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12811@debbugs.gnu.org
> 
> >> 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").

Sorry, I see no difference.

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

The code which implements these variables is the same code, it just
uses 3 different ways of computing where to put the window-start point
so that point winds up at the desired position within the window.
Once window-start was computed, the rest of the code is the same.

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

It is going back because we had many complaints before to prevent
centering point, when any of these variables were customized.  Most
complaints came from those who customize scroll-conservatively, but
that variable's effect is very similar to scroll-up/down-aggressively,
just expressed in other units.

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

Why is it undesirable?

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

No, the change made the code behave as documented, no matter how far
Emacs auto-scrolls.

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").
>
> Sorry, I see no difference.

This is the difference:
* For small jumps of point, both `scroll-up/down-aggressively' and
`scroll-step' provide a similar way of bringing point back into view.
They just measure the amount of scrolling in different units.
* But for large jumps, while the `scroll-step' semantics do a suitable
thing (i.e. display the current line centered), the semantics behind
`scroll-up/down-aggressively' do an undesirable thing (i.e. don't
display the current line centered).

So, I don't see how someone would want to use
`scroll-up/down-aggressively' at all.  They do a good thing only in
some situations (small jumps), but not in other common situations
(large jumps, as when Isearching or when doing 'M-g g' for example).

Then, given that these two variables are unsuitable, let's mark them
obsolete, no?  Nobody should miss them, because the good part of their
behavior would be available in `scroll-step' (just give it the
suitable fractional value).

I hope that now my proposal is better understood.

(Regarding your fix, I'll test it and report the results when the
emacs-24 branch is merged with the trunk)

-- 
Dani Moncayo

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

[Dani Moncayo]

> (Regarding your fix, I'll test it and report the results when the
> emacs-24 branch is merged with the trunk)

Since such merge has been made, I've tested the original recipe.  The
first test (related to `scroll-up-aggressively') now gives the
expected result (point shown at line 4 - 70% from the bottom).

The second test (related to `scroll-down-aggressively') produces a
better result (point shown at line 9 - 80% from the top) but not the
expected one (line 8 - 70% from the top).

In any case, since the result is almost the right one, and more
importantly, since I've discovered that these two variables are not
worth the trouble, I'm ok with closing this bug report now.

I'll make a new bug report (feature request) to allow `scroll-step'
accept also a fractional number.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Sun, 11 Nov 2012 14:33:33 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12811@debbugs.gnu.org
> 
> The second test (related to `scroll-down-aggressively') produces a
> better result (point shown at line 9 - 80% from the top) but not the
> expected one (line 8 - 70% from the top).

Emacs doesn't count in lines, it counts in pixels.  And since a line
has a finite size, where exactly those 70% end is not well determined
(is it the top of the line, the bottom of the line, somewhere in
between?).

> In any case, since the result is almost the right one, and more
> importantly, since I've discovered that these two variables are not
> worth the trouble, I'm ok with closing this bug report now.

Thanks, closing.

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

[Dani Moncayo]

> Emacs doesn't count in lines, it counts in pixels.  And since a line
> has a finite size, where exactly those 70% end is not well determined
> (is it the top of the line, the bottom of the line, somewhere in
> between?).

I don't see the point of using pixel as unit of measure here.  The
unit should be the line, because the problem to solve here can
(should) be expressed in terms of lines; going down to the pixel level
is unnecessary and confusing, IMO.

So, given a window which is W lines high, the line L that is X % from
the top of the window can be determined as

L = round((X/100)*(W-1))+1

Conversely, the percentage X from the top of the window can be determined as

X = 100*(L-1)/(W-1)

Therefore, testing with a window of W=11 lines high makes the above
calculations quite easy, because each line counts as 10%.

-- 
Dani Moncayo

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

[Eli Zaretskii]

> Date: Sun, 11 Nov 2012 17:55:59 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 12811@debbugs.gnu.org
> 
> > Emacs doesn't count in lines, it counts in pixels.  And since a line
> > has a finite size, where exactly those 70% end is not well determined
> > (is it the top of the line, the bottom of the line, somewhere in
> > between?).
> 
> I don't see the point of using pixel as unit of measure here.  The
> unit should be the line, because the problem to solve here can
> (should) be expressed in terms of lines; going down to the pixel level
> is unnecessary and confusing, IMO.

You forget about variable fonts.  One line can be very large, another
very small.  Scrolling must still do something reasonable with them.

> So, given a window which is W lines high

Since lines can have different heights, "W lines high" is not well
defined.  In extreme case, a window can be 1 line high, but scrolling
it bring 20 lines into view.

It is impossible to have reasonable scrolling if you go by lines.

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

[Dani Moncayo]

>> > Emacs doesn't count in lines, it counts in pixels.  And since a line
>> > has a finite size, where exactly those 70% end is not well determined
>> > (is it the top of the line, the bottom of the line, somewhere in
>> > between?).
>>
>> I don't see the point of using pixel as unit of measure here.  The
>> unit should be the line, because the problem to solve here can
>> (should) be expressed in terms of lines; going down to the pixel level
>> is unnecessary and confusing, IMO.
>
> You forget about variable fonts.  One line can be very large, another
> very small.  Scrolling must still do something reasonable with them.

Yes, I forgot that.  In that case we have to go down to the pixel level, indeed.

Thank you.

-- 
Dani Moncayo