all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dani Moncayo <dmoncayo@gmail.com>
Cc: 12811@debbugs.gnu.org
Subject: bug#12811: 24.3.50; `scroll-up/down-aggressively' don't seem to work as expected
Date: Wed, 07 Nov 2012 18:59:21 +0200	[thread overview]
Message-ID: <83r4o51h92.fsf@gnu.org> (raw)
In-Reply-To: <CAH8Pv0hmeAEDO+=vP_D+-5L6iegvdrRGAgC2k7_gZ830_snxDg@mail.gmail.com>

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





  parent reply	other threads:[~2012-11-07 16:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 23:27 bug#12811: 24.3.50; `scroll-up/down-aggressively' don't seem to work as expected Dani Moncayo
2012-11-06 16:54 ` Eli Zaretskii
2012-11-06 17:30   ` Eli Zaretskii
2012-11-06 19:18   ` Dani Moncayo
2012-11-06 21:36     ` Eli Zaretskii
2012-11-07  1:58       ` Juanma Barranquero
2012-11-07  9:23       ` Dani Moncayo
2012-11-07  9:34         ` Dani Moncayo
2012-11-07 16:59         ` Eli Zaretskii [this message]
2012-11-09 17:17           ` Dani Moncayo
2012-11-11 13:33             ` Dani Moncayo
2012-11-11 16:19               ` Eli Zaretskii
2012-11-11 16:55                 ` Dani Moncayo
2012-11-11 17:21                   ` Eli Zaretskii
2012-11-11 17:28                     ` Dani Moncayo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r4o51h92.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=12811@debbugs.gnu.org \
    --cc=dmoncayo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.