From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#13133: 24.2.90; scroll-conservatively is too coarse a setting Date: Tue, 11 Dec 2012 06:07:11 +0400 Message-ID: <50C6954F.5020104@yandex.ru> References: <87wqwqwpnf.fsf@vbx.i-did-not-set--mail-host-address--so-tickle-me> <83zk1mbert.fsf@gnu.org> <50C5855B.10703@yandex.ru> <83wqwqbd08.fsf@gnu.org> <50C59D4A.5020409@yandex.ru> <83r4myb86v.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1355191653 10611 80.91.229.3 (11 Dec 2012 02:07:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2012 02:07:33 +0000 (UTC) Cc: 13133@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 11 03:07:46 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TiFG5-0006hW-Ro for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Dec 2012 03:07:46 +0100 Original-Received: from localhost ([::1]:40560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiFFs-0006J2-VE for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Dec 2012 21:07:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiFFn-0006Iw-L6 for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 21:07:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiFFk-0007D1-Hu for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 21:07:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiFFk-0007Cw-EQ for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 21:07:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TiFGM-0005JF-Ho for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 21:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Dec 2012 02:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13133 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13133-submit@debbugs.gnu.org id=B13133.135519168020397 (code B ref 13133); Tue, 11 Dec 2012 02:08:02 +0000 Original-Received: (at 13133) by debbugs.gnu.org; 11 Dec 2012 02:08:00 +0000 Original-Received: from localhost ([127.0.0.1]:36080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiFGJ-0005Iv-9X for submit@debbugs.gnu.org; Mon, 10 Dec 2012 21:07:59 -0500 Original-Received: from mail-la0-f44.google.com ([209.85.215.44]:52054) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiFGE-0005Ij-Iy for 13133@debbugs.gnu.org; Mon, 10 Dec 2012 21:07:57 -0500 Original-Received: by mail-la0-f44.google.com with SMTP id d3so2982143lah.3 for <13133@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== Original-Received: by 10.152.104.226 with SMTP id gh2mr278303lab.24.1355191633664; Mon, 10 Dec 2012 18:07:13 -0800 (PST) Original-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) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <83r4myb86v.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:68300 Archived-At: On 10.12.2012 12:52, Eli Zaretskii wrote: >> Date: Mon, 10 Dec 2012 12:28:58 +0400 >> From: Dmitry Gutov >> 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.