From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise Date: Sat, 29 Sep 2018 14:48:46 +0000 Message-ID: <20180929144846.GC5008@ACM> References: <8336tv8iv7.fsf@gnu.org> <20180928203151.GB5172@ACM> <838t3l71ow.fsf@gnu.org> <20180929083551.GA4139@ACM> <83sh1s61mj.fsf@gnu.org> <20180929112520.GA5008@ACM> <83r2hc5sbf.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1538232794 6888 195.159.176.226 (29 Sep 2018 14:53:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 14:53:14 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 29 16:53:09 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6GcG-0001h0-SA for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 16:53:09 +0200 Original-Received: from localhost ([::1]:51248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6GeN-0000jJ-H1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 10:55:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6GeC-0000dr-6E for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 10:55:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6Ge6-0000zk-Mi for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 10:55:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54786) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6Ge6-0000zX-C1 for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 10:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6Ge6-0000j1-3D for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 10:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Sep 2018 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32848 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32848-submit@debbugs.gnu.org id=B32848.15382328632728 (code B ref 32848); Sat, 29 Sep 2018 14:55:02 +0000 Original-Received: (at 32848) by debbugs.gnu.org; 29 Sep 2018 14:54:23 +0000 Original-Received: from localhost ([127.0.0.1]:59044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6GdS-0000hv-MC for submit@debbugs.gnu.org; Sat, 29 Sep 2018 10:54:22 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:15607 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1g6GdQ-0000hn-VO for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 10:54:21 -0400 Original-Received: (qmail 92696 invoked by uid 3782); 29 Sep 2018 14:54:19 -0000 Original-Received: from acm.muc.de (p5B146BF5.dip0.t-ipconnect.de [91.20.107.245]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Sep 2018 16:54:18 +0200 Original-Received: (qmail 21065 invoked by uid 1000); 29 Sep 2018 14:48:46 -0000 Content-Disposition: inline In-Reply-To: <83r2hc5sbf.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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" Xref: news.gmane.org gmane.emacs.bugs:150762 Archived-At: Hello, Eli. On Sat, Sep 29, 2018 at 16:47:16 +0300, Eli Zaretskii wrote: > > Date: Sat, 29 Sep 2018 11:25:20 +0000 > > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org > > From: Alan Mackenzie > > I think my proposal from my last post is also safe and simple, it being > > a mere 5 lines (not counting comments) in one place in follow.el, and > > which is self contained. It ranks in complexity between your two > > proposals. > It isn't anywhere near safe in my book, sorry. Futzing with > window-start and other related variables is a minefield we better not > go into on the release branch. My patch doesn't do anything like that. It merely has a test, and if that test signals t, moves point by one line, away from the danger area. The messing around with window-start has been in follow mode for ever. I think it's time to post that patch: diff --git a/lisp/follow.el b/lisp/follow.el index fd397c077b..7d6204b08e 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -1385,7 +1385,15 @@ follow-adjust-window (unless (eq win (selected-window)) (let ((p (window-point win))) (set-window-start win (window-start win) nil) - (set-window-point win p)))) + (set-window-point win p) + (if (and frame-resize-pixelwise + make-cursor-line-fully-visible + ;; Check for cursor being in partially displayed line. + (nth 2 (pos-visible-in-window-p p win t))) + ;; If so, move point away from this disaster line, + ;; preventing scrolling. + (with-selected-window win + (forward-line -1)))))) (unless visible ;; If point may not be visible in the selected window, Please reconsider it, now you can see how little it actually does. > So if you don't think turning off make-cursor-line-fully-visible in > follow-mode buffers is an okay solution, the solution will have to > wait till Emacs 27, sorry. Turning off m-c-l-f-v I can live with, and if you definitely reject my approach above, I'm willing to implement it. It can't be difficult, just creating a buffer local variable and setting it to nil. ;-) [ .... ] > Users of follow-mode can choose whether they want the buggy behavior > we see now or give up fully-visible last line in the last window under > some rare situations (I couldn't even simulate those situations, btw). Fair enough! We are rather arguing about things which will rarely, if ever, happen. > > > Why is this better than what I proposed? > > It is simpler than allowing m-c-l-f-v be a function (which would involve > > amendments in xdisp.c, I think) > The changes in xdisp.c are a no-brainer, we already call several Lisp > functions in several places, and there's infrastructure ready for > that. OK. But it will be more complex than my 5-line patch above. But I have no objections to this change (making that variable optionally a function). > > > I proposed to allow make-cursor-line-fully-visible to have a value > > > that is a function, and let follow-mode define that function > > > accordingly, to make Emacs behave as if the last window in the group > > > had make-cursor-line-fully-visible set to the default or what the user > > > set it, and nil in all other windows under follow-mode. I think that > > > every solution that lets the display engine do the job is cleaner than > > > trying to force the display engine do that same job. > > Maybe. But follow mode is already a big fight with the display engine. > This one won't be a "fight" in any sense, just a call to a Lisp > function from C, that's all. And it happens in only one place. > > > Besides, your proposal has the annoying effect of causing a > > > micro-scroll near the end of the window. > > I don't see this (on GNU/Linux/X with GTK+ 3.22.30). > What, you mean you change the window-start and the text doesn't get > scrolled up to display starting from the new window-start? How can > that be? No, my patch doesn't change anything. Follow mode already does this: (set-window-start win (window-start win) nil) , which it does solely to prevent redisplay scrolling that buffer. It does not change window-start here. This is what I meant by follow mode and redisplay fighting. > Or maybe by "it" you meant move point? Then moving point is a side > effect I think we should avoid in this case. Point cannot stay in that partially displayed line. Follow mode moving it away prevents redisplay from scrolling the window. > > I was also thinking of amending the doc for set-window-start, to alert > > users to the possibility of a nil NOFORCE argument failing to prevent > > scrolling. If make-cursor-line-fully-visible were to become, > > optionally, a function there would be more reason to document it in the > > manual. > Fine with me, although saying in the docs that something doesn't have > to happen with 100% probability doesn't strike me as very helpful. The current docs imply NOFORCE being nil always works. If the docs had mentioned the exception, it's possible we wouldn't now be dealing with this bug. -- Alan Mackenzie (Nuremberg, Germany).