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: Tue, 11 Dec 2012 06:07:11 +0400

On 10.12.2012 12:52, Eli Zaretskii wrote:
>> Date: Mon, 10 Dec 2012 12:28:58 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> 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.

Previous Next

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