From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise Date: Sat, 29 Sep 2018 18:06:20 +0300 Message-ID: <83k1n45onn.fsf@gnu.org> 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> <20180929144846.GC5008@ACM> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538233511 27655 195.159.176.226 (29 Sep 2018 15:05:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 15:05:11 +0000 (UTC) Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 29 17:05:07 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 1g6Gnq-00075Q-BY for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 17:05:06 +0200 Original-Received: from localhost ([::1]:51273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6Gpx-0003p6-0S for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 11:07:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6Gpl-0003op-Kd for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 11:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6Gpi-0002Mj-Gs for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 11:07:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54795) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6Gpi-0002Mb-Cy for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 11:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6Gpi-000131-76 for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 11:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Sep 2018 15:07: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.15382336033994 (code B ref 32848); Sat, 29 Sep 2018 15:07:02 +0000 Original-Received: (at 32848) by debbugs.gnu.org; 29 Sep 2018 15:06:43 +0000 Original-Received: from localhost ([127.0.0.1]:59053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6GpP-00012M-Bq for submit@debbugs.gnu.org; Sat, 29 Sep 2018 11:06:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6GpN-000126-0U for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 11:06:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6GpE-000205-MR for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 11:06:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6GpE-000201-IW; Sat, 29 Sep 2018 11:06:32 -0400 Original-Received: from [176.228.60.248] (port=3700 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g6GpE-0000Um-5P; Sat, 29 Sep 2018 11:06:32 -0400 In-reply-to: <20180929144846.GC5008@ACM> (message from Alan Mackenzie on Sat, 29 Sep 2018 14:48:46 +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" Xref: news.gmane.org gmane.emacs.bugs:150763 Archived-At: > Date: Sat, 29 Sep 2018 14:48:46 +0000 > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org > From: Alan Mackenzie > > > 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)))))) But this means the user will have its command to move point down "ignored" in the window where she did that, right? IOW, I press C-n, and yet cursor stays in the line where I was before, right? > > 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. I think it will have a smaller effect than what you propose, yes. > It can't be difficult, just > creating a buffer local variable and setting it to nil. ;-) Right. > > 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. I volunteer to do the xdisp.c part if you will agree to write the follow.el function to serve as the value for make-cursor-line-fully-visible. > 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. I'm just saying that telling users it will sometimes not work, depending on factors that are really hard to describe, is not necessarily better. But I don't object.