GNU bug report logs - #13133
24.2.90; scroll-conservatively is too coarse a setting

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13133 <at> debbugs.gnu.org
Subject: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
Date: Mon, 10 Dec 2012 10:46:51 +0400

On 10.12.2012 10:30, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Mon, 10 Dec 2012 07:29:40 +0400
>>
>> I think this value is used in contexts that are different enough to
>> behave differently in this respect.
>>
>> 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.

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

Of other scroll- variables, I have scroll-preserve-screen-position set 
to t. Didn't think that matters.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.