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 16:47:16 +0300 Message-ID: <83r2hc5sbf.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538228766 15299 195.159.176.226 (29 Sep 2018 13:46:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 13:46:06 +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 15:46:02 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 1g6FZK-0003rh-5Z for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 15:46:02 +0200 Original-Received: from localhost ([::1]:51082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6FbQ-0006OB-RS for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 09:48:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6FbK-0006Nu-7w for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 09:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6FbG-0007lw-7z for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 09:48:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54144) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6FbG-0007lj-3K for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 09:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6FbF-0007KV-US for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 09:48: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: Sat, 29 Sep 2018 13:48:01 +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.153822886328151 (code B ref 32848); Sat, 29 Sep 2018 13:48:01 +0000 Original-Received: (at 32848) by debbugs.gnu.org; 29 Sep 2018 13:47:43 +0000 Original-Received: from localhost ([127.0.0.1]:58402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6Fax-0007Jy-F4 for submit@debbugs.gnu.org; Sat, 29 Sep 2018 09:47:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6Faw-0007Jn-Mg for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 09:47:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6Fal-0006x7-Rh for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 09:47:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6Faj-0006vk-P0; Sat, 29 Sep 2018 09:47:31 -0400 Original-Received: from [176.228.60.248] (port=2713 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g6Fai-0000Xx-6Q; Sat, 29 Sep 2018 09:47:29 -0400 In-reply-to: <20180929112520.GA5008@ACM> (message from Alan Mackenzie on Sat, 29 Sep 2018 11:25:20 +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:150757 Archived-At: > Date: Sat, 29 Sep 2018 11:25:20 +0000 > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org > From: Alan Mackenzie > > > > This feels a bit like a workaround > > > That's because it _is_ a workaround. But it's a safe one, so it can > > easily go into emacs-26, and solve most of this old bug. More complex > > solutions will have to go to master and wait till Emacs 27. WDYT > > about that? > > 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. 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. > > > Also, the user can change make-cursor-line-fully-visible at any > > > time, unlikely though this is. > > > Users can shoot themselves in the foot in many ways, but that's their > > funerals. We can always tell them "don't do that". > > Yes. This thing is a customisable option, however. 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). > > 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. > > 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? Or maybe by "it" you meant move point? Then moving point is a side effect I think we should avoid in this case. > 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.