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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: wishlist; Reported by: Dmitry Gutov <dgutov@HIDDEN>; dated Mon, 10 Dec 2012 03:31:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 11 Dec 2012 07:10:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 11 02:10:51 2012
Received: from localhost ([127.0.0.1]:36192 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TiJzO-0004mw-SU
	for submit <at> debbugs.gnu.org; Tue, 11 Dec 2012 02:10:51 -0500
Received: from mtaout22.012.net.il ([80.179.55.172]:62852)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <eliz@HIDDEN>) id 1TiJzL-0004mn-Tz
	for 13133 <at> debbugs.gnu.org; Tue, 11 Dec 2012 02:10:49 -0500
Received: from conversion-daemon.a-mtaout22.012.net.il by
	a-mtaout22.012.net.il (HyperSendmail v2007.08) id
	<0MEU00L00UKOBY00@HIDDEN> for
	13133 <at> debbugs.gnu.org; Tue, 11 Dec 2012 09:10:06 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
	(HyperSendmail v2007.08) with ESMTPA id
	<0MEU00LVBUKU7S10@HIDDEN>;
	Tue, 11 Dec 2012 09:10:06 +0200 (IST)
Date: Tue, 11 Dec 2012 09:09:59 +0200
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
In-reply-to: <50C6954F.5020104@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Message-id: <83pq2h9i9k.fsf@HIDDEN>
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN> <50C5855B.10703@HIDDEN>
	<83wqwqbd08.fsf@HIDDEN> <50C59D4A.5020409@HIDDEN>
	<83r4myb86v.fsf@HIDDEN> <50C6954F.5020104@HIDDEN>
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.2 (-)

> Date: Tue, 11 Dec 2012 06:07:11 +0400
> From: Dmitry Gutov <dgutov@HIDDEN>
> CC: 13133 <at> debbugs.gnu.org
> 
> On 10.12.2012 12:52, Eli Zaretskii wrote:
> >> Date: Mon, 10 Dec 2012 12:28:58 +0400
> >> From: Dmitry Gutov <dgutov@HIDDEN>
> >> CC: 13133 <at> debbugs.gnu.org
> >>
> >> Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think
> >> it's TRT?
> >
> > Because you generally want to see the entire definition of the API,
> > not just the opening brace or paren.
> 
> Not sure if I understand you here. For example, if I'm in an Elisp 
> function, I can press C-M-a to go to its beginning, and the whole 
> definition (including arglist and docstring) will be visible. If the 
> value of scroll-conservatively is small, though, the function body may 
> be cut in half.
> Or do you specifically mean non-lisp languages where the docstring is 
> above the function definition?

Yes, the latter.

> >> As far as I'm concerned, recentering might be fine when we go to the end
> >> of a small function (it will fit on the screen anyway), but a larger
> >> function, which might have fit on the full screen, will be cut in half.
> >
> > IMO, C-M-e/C-M-a is not for observing the whole function.  You may be
> > looking for a separate feature, or maybe a modification of an existing
> > feature.
> 
> I don't think you can reasonably decide what they are for.

I didn't decide anything, I just gave you my interpretation.  That's
what "IMO" is for.

> > Can you cook up a test case?  I'd like to see why this happens.  (If
> > showing this requires injection of specific amount of text into the
> > compilation buffer, you could use 'cat' or some similar program to do
> > so, instead of actually running a compiler.)
> 
> Here's one:

Thanks, I'll take a look.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 11 Dec 2012 02:08:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 21:07:59 2012
Received: from localhost ([127.0.0.1]:36080 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1TiFGJ-0005Iv-9X
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 21:07:59 -0500
Received: from mail-la0-f44.google.com ([209.85.215.44]:52054)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <raaahh@HIDDEN>) id 1TiFGE-0005Ij-Iy
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 21:07:57 -0500
Received: by mail-la0-f44.google.com with SMTP id d3so2982143lah.3
	for <13133 <at> debbugs.gnu.org>; Mon, 10 Dec 2012 18:07:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=AzVmnd01rR/cqC0LpqolimKfwg22VnOuRSXKVxlzXQk=;
	b=skafjprFqjrGjtK3nd1G2f4fpw6PD09ASBAqyB/qFNy8Bmkv6bWyKaklBmP/4p0UTW
	A3nrKq6vNfxhOQ8Z32A7G3oqw7i6FGLHTD8SXty3l5EwKz4YV8xsZq4sGz83IyWcE5fe
	ZETPaop648S6uIH/nwwomrZHdFSIX6Fvrx8j1FxAXK3mugh6GUOCUaRVe7qAHk1ZDrw/
	lkCHhvS2eqXxWC5HGN8tYEyqObNCkzMRo1dOKYljQEWMqm5OzrxIH2G62TR3DBB+aGd8
	fbwqWnLzD7pRzXbzVImpzXy6d8s61I+AfoZuvwurooyRT892zkEWlf6+N+f7fT/QRlP2
	tMaA==
Received: by 10.152.104.226 with SMTP id gh2mr278303lab.24.1355191633664;
	Mon, 10 Dec 2012 18:07:13 -0800 (PST)
Received: from [127.0.0.1] ([178.252.98.87])
	by mx.google.com with ESMTPS id so7sm8548526lab.0.2012.12.10.18.07.11
	(version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 18:07:12 -0800 (PST)
Message-ID: <50C6954F.5020104@HIDDEN>
Date: Tue, 11 Dec 2012 06:07:11 +0400
From: Dmitry Gutov <dgutov@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN> <50C5855B.10703@HIDDEN>
	<83wqwqbd08.fsf@HIDDEN> <50C59D4A.5020409@HIDDEN>
	<83r4myb86v.fsf@HIDDEN>
In-Reply-To: <83r4myb86v.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)

On 10.12.2012 12:52, Eli Zaretskii wrote:
>> Date: Mon, 10 Dec 2012 12:28:58 +0400
>> From: Dmitry Gutov <dgutov@HIDDEN>
>> CC: 13133 <at> debbugs.gnu.org
>>
>> Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think
>> it's TRT?
>
> Because you generally want to see the entire definition of the API,
> not just the opening brace or paren.

Not sure if I understand you here. For example, if I'm in an Elisp 
function, I can press C-M-a to go to its beginning, and the whole 
definition (including arglist and docstring) will be visible. If the 
value of scroll-conservatively is small, though, the function body may 
be cut in half.
Or do you specifically mean non-lisp languages where the docstring is 
above the function definition?

>> As far as I'm concerned, recentering might be fine when we go to the end
>> of a small function (it will fit on the screen anyway), but a larger
>> function, which might have fit on the full screen, will be cut in half.
>
> IMO, C-M-e/C-M-a is not for observing the whole function.  You may be
> looking for a separate feature, or maybe a modification of an existing
> feature.

I don't think you can reasonably decide what they are for. When a 
command moves viewport, I think it's reasonable to use it for that 
purpose. Not that that's the only purpose I use them for, but in general 
I prefer when the body of a function displayed in a buffer is not split 
in half.

Also, I'd prefer if end-of-definition's behavior didn't depend on the 
length of the function it acts on. It's a little disorienting.

>>>> 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?
>>
>> Without.
>
> Can you cook up a test case?  I'd like to see why this happens.  (If
> showing this requires injection of specific amount of text into the
> compilation buffer, you could use 'cat' or some similar program to do
> so, instead of actually running a compiler.)

Here's one:

~/tesh.sh:

#!/bin/bash
for i in `seq 1 125`;
do
     echo "Lorem ipsum"
done

eval:

(setq scroll-conservatively 10)

(let ((compilation-scroll-output t)) (compile "~/test.sh"))

In the end, in 54-line window, the text "Compilation finished" ends up 
on line 26.

>>> 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".
>>
>> If I had to guess, it might be that people just wanted out of the
>> default always-recentering behavior, and it was a quick way to end the
>> discussion and get the implementation.
>>
>> Anyway, I don't remember seeing that poll. And if you were asking on
>> emacs-devel, that doesn't exactly represent the majority of users.
>
> Emacs 24.x with this feature was released 6 months ago, and I have yet
> to see a single complaint about it -- until now.  What user poll can
> possibly match that?

Not sure. But it is a low-level feature that's not exactly trivial to 
reason about. So a user might not think it's a bug worth reporting, even 
if they don't like the behavior.

For example, when I migrated to Emacs 24, I remember reading about the 
improvements to scroll-conservatively, so setting it to 101 was one of 
the first things I did. Then I noticed that it makes imenu and 
help-button-action only scroll as far as the first line of the function 
definition, which is something I don't believe anyone can find optimal.
So I set the variable value to 5, which allowed next/previous-line 
scrolling without recentering, and at the same time usually makes code 
navigation commands recenter. I haven't used compilation buffer much 
until recently. But this value of 5 is bad in subtle ways.

Aside from what I mentioned about compilation, *-of-defun, *-sentence 
and similar commands, the behavior of imenu and help-button-action that 
comes with any positive value of scroll-conservatively is strange. Sure, 
that's a rare case, but what if the function I'm looking for is 3 or 5 
lines below the last window line? Then imenu won't recenter on it. That 
makes no sense.

I'd rather they used some other variable that allowed to specify the 
number of lines that the function I navigated to is allowed to be from 
the window boundary. Closer than 4 lines? Recenter! Or maybe always 
recenter, or put the first line of the function at 1/3rd of the window 
height from the top.

>> But that won't help with C-M-a/C-M-e and, I don't know, any other
>> buffers with deal with process output?
>
> "M-x shell" comes to mind.

It passes my test case. Calling ~/test.sh doesn't make the prompt line 
scroll to the middle of the window. Same for inf-ruby (derived from 
comint-mode).

>>> 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.
>>
>> Do you like the behavior of compilation buffer often having wasted
>> space, or do you just not mind it (with monitors being cheap and all)? I
>> don't see what anyone could really like about it.
>
> Very simple: I don't watch the compilation messages as they come in.
> It's a waste of time; I continue editing or doing something else while
> the compiler churns away.  To me, watching the messages is a relic
> from old DOS days when I couldn't do anything while waiting for the
> compiler to finish.
>
> I only look at the compiler messages when compilation finishes, and
> then I either scroll through the buffer or use "C-x `".  In both
> cases, what redisplay does when a new message comes in is of no
> interest to me.

I'm also only interested in what the window looks like when the 
compilation is finished. But I want to be able to see as much of the log 
as possible without scrolling or invoking any other commands.

I'm not compiling anything, actually, just calling rspec and looking at 
the output.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 08:53:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 03:53:13 2012
Received: from localhost ([127.0.0.1]:34840 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Thz6u-0004Iv-VI
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 03:53:13 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:62161)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <eliz@HIDDEN>) id 1Thz6s-0004Ik-1E
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 03:53:11 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
	a-mtaout20.012.net.il (HyperSendmail v2007.08) id
	<0MET002004L5Y700@HIDDEN> for
	13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 10:52:34 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
	(HyperSendmail v2007.08) with ESMTPA id
	<0MET002C84NLYB00@HIDDEN>;
	Mon, 10 Dec 2012 10:52:34 +0200 (IST)
Date: Mon, 10 Dec 2012 10:52:24 +0200
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
In-reply-to: <50C59D4A.5020409@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Message-id: <83r4myb86v.fsf@HIDDEN>
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN> <50C5855B.10703@HIDDEN>
	<83wqwqbd08.fsf@HIDDEN> <50C59D4A.5020409@HIDDEN>
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
	has
	identified this incoming email as possible spam. The original message
	has been attached to this so you can view it (if it isn't spam) or
	label similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  > Date: Mon,
	10 Dec 2012 12:28:58 +0400 > From: Dmitry Gutov
	<dgutov@HIDDEN> > CC: 13133 <at> debbugs.gnu.org > > Like I mentioned,
	I don't
	want C-M-e/C-M-a to recenter. Why do you think > it's TRT? Because you
	generally
	want to see the entire definition of the API, not just the opening brace
	or paren. [...] 
	Content analysis details:   (1.5 points, 10.0 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.179.55.166 listed in list.dnswl.org]
	0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
	[score: 0.4867]
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.2 (-)

> Date: Mon, 10 Dec 2012 12:28:58 +0400
> From: Dmitry Gutov <dgutov@HIDDEN>
> CC: 13133 <at> debbugs.gnu.org
> 
> Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think 
> it's TRT?

Because you generally want to see the entire definition of the API,
not just the opening brace or paren.

> As far as I'm concerned, recentering might be fine when we go to the end 
> of a small function (it will fit on the screen anyway), but a larger 
> function, which might have fit on the full screen, will be cut in half.

IMO, C-M-e/C-M-a is not for observing the whole function.  You may be
looking for a separate feature, or maybe a modification of an existing
feature.

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

Can you cook up a test case?  I'd like to see why this happens.  (If
showing this requires injection of specific amount of text into the
compilation buffer, you could use 'cat' or some similar program to do
so, instead of actually running a compiler.)

> > 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".
> 
> If I had to guess, it might be that people just wanted out of the 
> default always-recentering behavior, and it was a quick way to end the 
> discussion and get the implementation.
> 
> Anyway, I don't remember seeing that poll. And if you were asking on 
> emacs-devel, that doesn't exactly represent the majority of users.

Emacs 24.x with this feature was released 6 months ago, and I have yet
to see a single complaint about it -- until now.  What user poll can
possibly match that?

> > Another possibility would be to add more customization values to
> > compilation-scroll-output, implementing the behavior of your
> > compile-scroll-eob.
> 
> Yes, sure. Just set buffer-local value of scroll-conservatively, maybe?

Could be.  But I think it is best first to define the required
behavior first.  Then we can see if setting scroll-conservatively
would fit the bill.

> But that won't help with C-M-a/C-M-e and, I don't know, any other 
> buffers with deal with process output?

"M-x shell" comes to mind.

> > 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.
> 
> Do you like the behavior of compilation buffer often having wasted 
> space, or do you just not mind it (with monitors being cheap and all)? I 
> don't see what anyone could really like about it.

Very simple: I don't watch the compilation messages as they come in.
It's a waste of time; I continue editing or doing something else while
the compiler churns away.  To me, watching the messages is a relic
from old DOS days when I couldn't do anything while waiting for the
compiler to finish.

I only look at the compiler messages when compilation finishes, and
then I either scroll through the buffer or use "C-x `".  In both
cases, what redisplay does when a new message comes in is of no
interest to me.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 08:29:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 03:29:38 2012
Received: from localhost ([127.0.0.1]:34831 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Thyk6-0003mO-B0
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 03:29:38 -0500
Received: from mail-la0-f44.google.com ([209.85.215.44]:56585)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <raaahh@HIDDEN>) id 1Thyk3-0003mA-6B
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 03:29:36 -0500
Received: by mail-la0-f44.google.com with SMTP id d3so2145056lah.3
	for <13133 <at> debbugs.gnu.org>; Mon, 10 Dec 2012 00:28:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=D+wiQNFCSh572bxOOqap33DnUVI93gp8NTyYLJskTeY=;
	b=xLpmIFJH1zHKh/hiLp0I9L6EbQuxM20QOGCnlTR9pU46KNkJeNIEKBmzd/DX0gyAPv
	3hSdG1alihz5u3mFa/vqHqrrZZ4awbx4LNmOa683I2byKHMlvVKO9dGG+cl/L71Bwiaq
	sRvnYcFzSwwYVx4IQpWqEHQKhB7UbrfEcMNm8sMZIiBeFxKCa4yMhiG6MdckrdvSaEDr
	at0018ADZtPTQwwyc1DIgB8jENHb9zdF+yR6L40r+lvQHFJ7WeK0PoOETCQm5bl79sPX
	dq6jSlJ6Lg7Di8qYXz0dYT0AouPv8tMkeDzJi0rK1OKjSRGodhCAgUiJmuZeQyeKkgo/
	jJtQ==
Received: by 10.112.23.136 with SMTP id m8mr5777679lbf.16.1355128138210;
	Mon, 10 Dec 2012 00:28:58 -0800 (PST)
Received: from [127.0.0.1] ([178.252.98.87])
	by mx.google.com with ESMTPS id sq2sm7360290lab.14.2012.12.10.00.28.56
	(version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 00:28:56 -0800 (PST)
Message-ID: <50C59D4A.5020409@HIDDEN>
Date: Mon, 10 Dec 2012 12:28:58 +0400
From: Dmitry Gutov <dgutov@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN> <50C5855B.10703@HIDDEN>
	<83wqwqbd08.fsf@HIDDEN>
In-Reply-To: <83wqwqbd08.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.6 (--)

On 10.12.2012 11:08, Eli Zaretskii wrote:
>> Date: Mon, 10 Dec 2012 10:46:51 +0400
>> From: Dmitry Gutov <dgutov@HIDDEN>
>> CC: 13133 <at> 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?

Just tried that with compilation, didn't help. In fact, I have to set it 
as large as 50 to not see empty space in the window (tried 40, no dice).
And that's with one specific compilation process. Run something that's 
twice as verbose, and the value will have to be 100, no?

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

Like I mentioned, I don't want C-M-e/C-M-a to recenter. Why do you think 
it's TRT?
As far as I'm concerned, recentering might be fine when we go to the end 
of a small function (it will fit on the screen anyway), but a larger 
function, which might have fit on the full screen, will be cut in half.

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

Without.

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

If I had to guess, it might be that people just wanted out of the 
default always-recentering behavior, and it was a quick way to end the 
discussion and get the implementation.

Anyway, I don't remember seeing that poll. And if you were asking on 
emacs-devel, that doesn't exactly represent the majority of users.

I don't think I'm asking for anything exotic here, really. I think all 3 
items are pretty much the standard in "modern" editors or IDEs.

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

Yes, sure. Just set buffer-local value of scroll-conservatively, maybe?

But that won't help with C-M-a/C-M-e and, I don't know, any other 
buffers with deal with process output? I think the compilation buffer is 
a great example that not only doesn't have anything to do with 
scrolling, but also is unrelated to code navigation. And still, 
scroll-conservatively is used there.

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

Do you like the behavior of compilation buffer often having wasted 
space, or do you just not mind it (with monitors being cheap and all)? I 
don't see what anyone could really like about it.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 07:09:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 02:09:14 2012
Received: from localhost ([127.0.0.1]:34779 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ThxUI-0001zZ-14
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 02:09:14 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:51878)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <eliz@HIDDEN>) id 1ThxUF-0001zP-EQ
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 02:09:12 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
	a-mtaout20.012.net.il (HyperSendmail v2007.08) id
	<0MES00100ZSZAG00@HIDDEN> for
	13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 09:08:33 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
	(HyperSendmail v2007.08) with ESMTPA id
	<0MES000XAZU8UQ80@HIDDEN>;
	Mon, 10 Dec 2012 09:08:32 +0200 (IST)
Date: Mon, 10 Dec 2012 09:08:23 +0200
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
In-reply-to: <50C5855B.10703@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Message-id: <83wqwqbd08.fsf@HIDDEN>
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN> <50C5855B.10703@HIDDEN>
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
	has
	identified this incoming email as possible spam. The original message
	has been attached to this so you can view it (if it isn't spam) or
	label similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  > Date: Mon,
	10 Dec 2012 10:46:51 +0400 > From: Dmitry Gutov
	<dgutov@HIDDEN> > CC: 13133 <at> 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. [...] 
	Content analysis details:   (1.5 points, 10.0 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.179.55.166 listed in list.dnswl.org]
	0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
	[score: 0.4936]
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.2 (-)

> Date: Mon, 10 Dec 2012 10:46:51 +0400
> From: Dmitry Gutov <dgutov@HIDDEN>
> CC: 13133 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 06:47:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 01:47:31 2012
Received: from localhost ([127.0.0.1]:34758 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Thx9G-0001W4-8n
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 01:47:30 -0500
Received: from mail-lb0-f172.google.com ([209.85.217.172]:58046)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <raaahh@HIDDEN>) id 1Thx9D-0001Vw-PA
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 01:47:29 -0500
Received: by mail-lb0-f172.google.com with SMTP id y2so2179825lbk.3
	for <13133 <at> debbugs.gnu.org>; Sun, 09 Dec 2012 22:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=NZezJngzf41hh69mDzUawFDRGJDGQ4Z0E8u2LTK0PYU=;
	b=1CeW7V8ldBEtuE7fRNPLGSfFe9BYt20UN8TlOf/iJ/xqKZyPD7I1skraijZVCX4F3G
	GXMQVUW3RLUuWpBmKw9EAnIiak2G+gu0NUhhoJ2UwPlmJ7t44DlJApyqr6Ii+QLosB/m
	JjFMxk9MSgNGRk8Zshs1tATjNPJknrpHOycexTM/0MVFjZD1OqAYupf9lat9KoTRikdK
	80cOrP0d0CYTMWgWpQ2wjXhEQeiSh5CwvPmpxj238qzG/GfoBfvzvQtlg1Wkco4t0IA7
	Sy3QKEV0Lc8bB0MALUKVp7YJbjNwHsSjQDI9xAPnuQmqLVbfkpX+kFXrKqtf/54AmGm5
	61NA==
Received: by 10.152.114.65 with SMTP id je1mr12932857lab.33.1355122011581;
	Sun, 09 Dec 2012 22:46:51 -0800 (PST)
Received: from [127.0.0.1] ([178.252.98.87])
	by mx.google.com with ESMTPS id b3sm7337296lbl.0.2012.12.09.22.46.49
	(version=SSLv3 cipher=OTHER); Sun, 09 Dec 2012 22:46:50 -0800 (PST)
Message-ID: <50C5855B.10703@HIDDEN>
Date: Mon, 10 Dec 2012 10:46:51 +0400
From: Dmitry Gutov <dgutov@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
References: <87wqwqwpnf.fsf@HIDDEN>
	<83zk1mbert.fsf@HIDDEN>
In-Reply-To: <83zk1mbert.fsf@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -0.7 (/)

On 10.12.2012 10:30, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@HIDDEN>
>> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at 13133 <at> debbugs.gnu.org:


Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 06:31:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 10 01:31:12 2012
Received: from localhost ([127.0.0.1]:34752 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ThwtK-0001AK-VD
	for submit <at> debbugs.gnu.org; Mon, 10 Dec 2012 01:31:11 -0500
Received: from mtaout22.012.net.il ([80.179.55.172]:61920)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <eliz@HIDDEN>) id 1ThwtH-0001A4-Ig
	for 13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 01:31:01 -0500
Received: from conversion-daemon.a-mtaout22.012.net.il by
	a-mtaout22.012.net.il (HyperSendmail v2007.08) id
	<0MES00400Y14S000@HIDDEN> for
	13133 <at> debbugs.gnu.org; Mon, 10 Dec 2012 08:30:24 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
	(HyperSendmail v2007.08) with ESMTPA id
	<0MES004G7Y2NR610@HIDDEN>;
	Mon, 10 Dec 2012 08:30:24 +0200 (IST)
Date: Mon, 10 Dec 2012 08:30:14 +0200
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
In-reply-to: <87wqwqwpnf.fsf@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Message-id: <83zk1mbert.fsf@HIDDEN>
References: <87wqwqwpnf.fsf@HIDDEN>
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
	has
	identified this incoming email as possible spam. The original message
	has been attached to this so you can view it (if it isn't spam) or
	label similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  > From: Dmitry Gutov <dgutov@HIDDEN> > 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). [...] 
	Content analysis details:   (1.5 points, 10.0 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.179.55.172 listed in list.dnswl.org]
	0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
	[score: 0.5000]
X-Debbugs-Envelope-To: 13133
Cc: 13133 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > From: Dmitry Gutov <dgutov@HIDDEN> > 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). [...] 
 
 Content analysis details:   (1.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [80.179.55.172 listed in list.dnswl.org]
  0.7 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
  0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                             [score: 0.4969]

> From: Dmitry Gutov <dgutov@HIDDEN>
> 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.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 10 Dec 2012 03:30:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 09 22:30:45 2012
Received: from localhost ([127.0.0.1]:34622 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Thu4q-0005XC-3t
	for submit <at> debbugs.gnu.org; Sun, 09 Dec 2012 22:30:44 -0500
Received: from eggs.gnu.org ([208.118.235.92]:35332)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <raaahh@HIDDEN>) id 1Thu4m-0005X3-6L
	for submit <at> debbugs.gnu.org; Sun, 09 Dec 2012 22:30:41 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <raaahh@HIDDEN>) id 1Thu49-0005kv-27
	for submit <at> debbugs.gnu.org; Sun, 09 Dec 2012 22:30:07 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:37738)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <raaahh@HIDDEN>) id 1Thu48-0005kq-SZ
	for submit <at> debbugs.gnu.org; Sun, 09 Dec 2012 22:30:00 -0500
Received: from eggs.gnu.org ([208.118.235.92]:46661)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <raaahh@HIDDEN>) id 1Thu43-0008Oz-RV
	for bug-gnu-emacs@HIDDEN; Sun, 09 Dec 2012 22:30:00 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <raaahh@HIDDEN>) id 1Thu3z-0005jk-Ru
	for bug-gnu-emacs@HIDDEN; Sun, 09 Dec 2012 22:29:55 -0500
Received: from mail-lb0-f169.google.com ([209.85.217.169]:33838)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <raaahh@HIDDEN>) id 1Thu3z-0005jg-KL
	for bug-gnu-emacs@HIDDEN; Sun, 09 Dec 2012 22:29:51 -0500
Received: by mail-lb0-f169.google.com with SMTP id gk1so1918334lbb.0
	for <bug-gnu-emacs@HIDDEN>; Sun, 09 Dec 2012 19:29:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:from:to:subject:date:message-id:mime-version:content-type;
	bh=O4oMgE+qyWAOg++JUpvrtmFMpqgZj6c3e3TtdwlPX9Y=;
	b=fTC3FNRJirgj4G1DKuhK137hYFg6pZ645BIdOywz7FO4eJXgJUl25wKWYQlGn5pwwq
	uL9tftgY4wSw4O3t5sK59qbYPxCgtAB1Hoc5EkhqSSjQO0oG1myHwpdJ1veKX2G2g1+I
	GLg/78zT1421A0Qxj5BCqMzl/JR2Mydywrs2WyeguzBRvYuCkNHJerCSCe71Sd3+++NE
	UhIATM453J3N0nPn4C6QMGjwCq1Nb1UEs4WK63ndXom/BDVGKBoKjae1rIQSXhvXWvYS
	lakSMxtvYWrxo0mS/S46xTMwkxbbSr+0+tldeQGY+lEKMoi+tJjCpFGJDnMbPZyUT0xC
	8z3g==
Received: by 10.152.129.197 with SMTP id ny5mr12442488lab.43.1355110190597;
	Sun, 09 Dec 2012 19:29:50 -0800 (PST)
Received: from vbx ([178.252.98.87])
	by mx.google.com with ESMTPS id p5sm7200560lbh.2.2012.12.09.19.29.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Dec 2012 19:29:48 -0800 (PST)
From: Dmitry Gutov <dgutov@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 24.2.90; scroll-conservatively is too coarse a setting
Date: Mon, 10 Dec 2012 07:29:40 +0400
Message-ID: <87wqwqwpnf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.2 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.1 (------)

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

Thoughts?

So far I'm doing this for the compilation buffer:

(defun compile-scroll-eob (buffer _status)
  (let ((win (get-buffer-window buffer))
        (current (selected-window)))
    (when win
      (select-window win)
      (with-current-buffer buffer
        (when (> (line-number-at-pos (point-max)) (window-height))
          (goto-char (point-max))
          (recenter (window-height))))
      (select-window current))))

(add-to-list 'compilation-finish-functions 'compile-scroll-eob)

I think that behavior should be the default, though.

In GNU Emacs 24.2.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
 of 2012-11-26 on vbx
Bzr revision: 110959 rgm@HIDDEN
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.10




Acknowledgement sent to Dmitry Gutov <dgutov@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#13133; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

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