bug#13133: 24.2.90; scroll-conservatively is too coarse a setting

[Eli Zaretskii]

> Date: Mon, 10 Dec 2012 10:46:51 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 13133@debbugs.gnu.org
> 
> >> Examples:
> >> 1) I want help-button-action to bring me to the function's definition,
> >> and I generally want in the middle of the screen. Same for imenu, etc.
> >> 2) I really don't want to see empty space after the contents in the
> >> compilation window. But as much as half of the window may be empty right
> >> after compilation because of the point recentering.
> >> 3) Ideally, if I move around with next/previous-line, I don't want
> >> sudden jumps and recenterings. Same thing with beginning/end-of-defun
> >> (so setting scroll-conservatively to a value larger than 0 is not a real
> >> solution).
> >
> > I'm sorry, but the problem you describing is entirely unclear to me.
> > You didn't say what value, if any, did you set scroll-conservatively
> > to, nor if you have any other scroll-* variables customized to
> > non-default values.  If you don't customize anything, Emacs always
> > re-centers when point goes out of sight.  When point is re-centered, I
> > don't think you can ever have half-window of empty space, because of
> > the way re-centering works.
> >
> > Given this lack of information, I don't understand how you get the
> > adverse effects in your 3 examples.  Please elaborate, perhaps
> > separately about each of the examples.
> 
> The problem is getting all 3 to work at the same time.
> 
> For 1, scroll-conservatively needs to be < 100, something like 0-10, so 
> that recentering usually happens.
> For 2, I have to set scroll-conservatively to 101. Some lower values may 
> also help, but there's no guarantee, as I understand it: the contents of 
> the compilation buffer are getting added in large chunks.
> For 3, again, I have to set scroll-conservatively to a large value. For 
> C-n/C-p, the value of 5 is usually enough, for for C-M-e/C-M-a, it often 
> has to be larger than that.

Why can't you use a value of scroll-conservatively around 10, then?
The way I see it, the only problem might be with 2, and even there I'm
not sure you will see it frequently, or ever.  For 3, C-M-e/C-M-a will
DTRT and show point in the middle of the window, unless the function
is very short, in which case point will be near the beginning or end
of the window; again, TRT.

> Half-window happens because when the compilation buffer is filled, the 
> point is at the end of it (when compilation-scroll-output is t, at least).

Does this happen with or without setting scroll-conservatively to a
value larger than 100?

Just for the record: when I asked whether people who like Emacs to
_never_ recenter would mind having that behavior in contexts that have
nothing to do with scrolling, the response was a huge YES.  So the
current behavior seems to be "by popular demand".

Another possibility would be to add more customization values to
compilation-scroll-output, implementing the behavior of your
compile-scroll-eob.

I won't argue what the default behavior should be, because it tends to
become bike-shedding very fast.  FWIW, I use the default behavior,
without customizing any scroll-related variables, and like that
behavior, including in compilation buffers.