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: Mon, 10 Dec 2012 12:28:58 +0400 Message-ID: <50C59D4A.5020409@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1355128181 21242 80.91.229.3 (10 Dec 2012 08:29:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2012 08:29:41 +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 Mon Dec 10 09:29:54 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 1ThykI-0001HQ-La for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Dec 2012 09:29:50 +0100 Original-Received: from localhost ([::1]:51413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thyk6-0004Uy-41 for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Dec 2012 03:29:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thyjz-0004IM-Sn for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 03:29:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Thyjx-0003fN-4v for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 03:29:31 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thyjx-0003fI-0z for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 03:29:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1ThykU-0003nd-UN for bug-gnu-emacs@gnu.org; Mon, 10 Dec 2012 03:30: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: Mon, 10 Dec 2012 08:30: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.135512817914535 (code B ref 13133); Mon, 10 Dec 2012 08:30:02 +0000 Original-Received: (at 13133) by debbugs.gnu.org; 10 Dec 2012 08:29:39 +0000 Original-Received: from localhost ([127.0.0.1]:34831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Thyk6-0003mO-B0 for submit@debbugs.gnu.org; Mon, 10 Dec 2012 03:29:38 -0500 Original-Received: from mail-la0-f44.google.com ([209.85.215.44]:56585) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Thyk3-0003mA-6B for 13133@debbugs.gnu.org; Mon, 10 Dec 2012 03:29:36 -0500 Original-Received: by mail-la0-f44.google.com with SMTP id d3so2145056lah.3 for <13133@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== Original-Received: by 10.112.23.136 with SMTP id m8mr5777679lbf.16.1355128138210; Mon, 10 Dec 2012 00:28:58 -0800 (PST) Original-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) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <83wqwqbd08.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:68267 Archived-At: On 10.12.2012 11:08, Eli Zaretskii wrote: >> Date: Mon, 10 Dec 2012 10:46:51 +0400 >> From: Dmitry Gutov >> CC: 13133@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.