[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13133: 24.2.90; scroll-conservatively is too coarse a setting
From: |
Dmitry Gutov |
Subject: |
bug#13133: 24.2.90; scroll-conservatively is too coarse a setting |
Date: |
Tue, 11 Dec 2012 06:07:11 +0400 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 10.12.2012 12:52, Eli Zaretskii wrote:
Date: Mon, 10 Dec 2012 12:28:58 +0400
From: Dmitry Gutov <dgutov@yandex.ru>
CC: 13133@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.