From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23098: 25.0.92; (recenter -1) can leave point in the middle of the window Date: Mon, 28 Mar 2016 20:28:19 +0300 Message-ID: <83bn5yy0jw.fsf@gnu.org> References: <87r3f19gx0.fsf@loki.jorgenschaefer.de> <83d1ql2ebx.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1459186909 8304 80.91.229.3 (28 Mar 2016 17:41:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2016 17:41:49 +0000 (UTC) Cc: jwiegley@gmail.com, 23098@debbugs.gnu.org To: Jorgen =?UTF-8?Q?Sch=C3=A4fer?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 19:41:38 2016 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 1akayW-0004kX-DE for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2016 19:29:12 +0200 Original-Received: from localhost ([::1]:41930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akayV-0004sI-BF for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2016 13:29:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akayR-0004sC-BB for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 13:29:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akayM-0003JH-7f for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 13:29:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akayM-0003J3-3M for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 13:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1akayL-0002pW-Vi for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 13:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Mar 2016 17:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23098 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23098-submit@debbugs.gnu.org id=B23098.145918613210861 (code B ref 23098); Mon, 28 Mar 2016 17:29:01 +0000 Original-Received: (at 23098) by debbugs.gnu.org; 28 Mar 2016 17:28:52 +0000 Original-Received: from localhost ([127.0.0.1]:42314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akayB-0002p7-W8 for submit@debbugs.gnu.org; Mon, 28 Mar 2016 13:28:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akay9-0002ou-VP for 23098@debbugs.gnu.org; Mon, 28 Mar 2016 13:28:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akaxz-00032G-QS for 23098@debbugs.gnu.org; Mon, 28 Mar 2016 13:28:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akaxz-00032C-Mk; Mon, 28 Mar 2016 13:28:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4827 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1akaxy-0008OH-TT; Mon, 28 Mar 2016 13:28:39 -0400 In-reply-to: (message from Jorgen =?UTF-8?Q?Sch=C3=A4fer?= on Mon, 28 Mar 2016 13:10:23 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:115668 Archived-At: > From: Jorgen Schäfer > Date: Mon, 28 Mar 2016 13:10:23 +0000 > Cc: 23098@debbugs.gnu.org > > As an end user, I expect `recenter-to-bottom' to cycle the line with point on it between the top, middle and > bottom of the current window. The problem described in this report means that Emacs does not actually do > this – the line with point on it does not ever go even near the bottom of the window. You are judging what Emacs does by the end result: since the result is not to have point near the bottom, you deduce that Emacs didn't even try. But that is false. What actually happens is that Emacs did try to do what (recenter -1) requested, except that the display engine found that doing so would have ended up with point being outside of the window. Since this is not acceptable, the display engine gave up and recentered point in the window instead. > There is a technical reason for this problem: Emacs can not, actually, display a multi-line overlay only partly. > This is a shortcoming of Emacs, but I assume this is non-trivial to fix. When Emacs notices it can not fulfill a > scroll request, it will use a fall back algorithm. Yes. > When I, as a user, try to display a line at the bottom of a window, it would appear to me that trying to keep the > line as close to the bottom as possible instead of the middle of the window is a better fall back. The problem is discovered at redisplay time, by some generic code that has no direct relation to recentering, it gets run any time some command requests that display of a window starts at a specified position. The fallback you'd like is more expensive, so using it in that code would punish users who don't bump into this use case and don't care about it. Setting scroll-conservatively is the way to tell Emacs you are generally prepared to deal with more expensive (i.e. slower) redisplay if that gives you more accurate scrolling. That's why, when scroll-conservatively is set to a large value, the display engine does try a more accurate (and more expensive) fallback. But doing that always, without the user's say-so, would be a misfeature, I think. > Setting scroll-conservatively to a large value is a way for the user to work around this behavior. But this > workaround also affects all the other times a user tries to scroll the buffer. So this is not a fix, it's a > workaround with unintended and rather large side effects completely unrelated to this. I actually don't understand why you don't want to set scroll-conservatively globally. From what you say, it sounds like that variable is exactly what you want, and not only in this situation. Can you explain why you don't see that as a solution? > A similar problems exist for programmers trying to implement a specific behavior in buffers without > prescribing to users how their normal scrolling behaves. The idea is that users who are bothered by such use cases are expected to like the effect of scroll-conservatively everywhere. > This situation strikes me as an issue Emacs could address. I'd welcome patches to try to fix this, but I think the best fix is inside 'recenter': it should detect this situation and behave as if its argument was modified so as not to request redisplay of the window with window-start point that will cause recentering of point. For example, in the test case you presented, 'recenter' should behave as if it was called with an argument of -2, not -1. The tricky part is to implement a strategy that will do reasonable things when the overlay or display string takes more than one line: depending on the original value of the argument to 'recenter', sometimes you'd want it increased, and sometimes decreased. Interested?