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 11:25:20 +0000 Message-ID: <20180929112520.GA5008@ACM> References: <8336tv8iv7.fsf@gnu.org> <20180928203151.GB5172@ACM> <838t3l71ow.fsf@gnu.org> <20180929083551.GA4139@ACM> <83sh1s61mj.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 1538222427 26736 195.159.176.226 (29 Sep 2018 12:00:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 12:00:27 +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 14:00:22 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 1g6Dv4-0006pz-6N for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 14:00:22 +0200 Original-Received: from localhost ([::1]:50745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6DxA-00014g-Js for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 08:02:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6Dx3-0000xC-Ti for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 08:02:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6Dwx-0008Vu-2M for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 08:02:23 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54091) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6DSg-0004yb-4H for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 07:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6DSf-0002u6-Sv for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 07:31:01 -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 11:31: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.153822065710883 (code B ref 32848); Sat, 29 Sep 2018 11:31:01 +0000 Original-Received: (at 32848) by debbugs.gnu.org; 29 Sep 2018 11:30:57 +0000 Original-Received: from localhost ([127.0.0.1]:58349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6DSa-0002p0-F4 for submit@debbugs.gnu.org; Sat, 29 Sep 2018 07:30:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:21049 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1g6DSY-0002m3-0B for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 07:30:54 -0400 Original-Received: (qmail 22943 invoked by uid 3782); 29 Sep 2018 11:30:52 -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 13:30:52 +0200 Original-Received: (qmail 20450 invoked by uid 1000); 29 Sep 2018 11:25:20 -0000 Content-Disposition: inline In-Reply-To: <83sh1s61mj.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:150755 Archived-At: Hello, Eli. On Sat, Sep 29, 2018 at 13:26:12 +0300, Eli Zaretskii wrote: > > Date: Sat, 29 Sep 2018 08:35:51 +0000 > > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org > > From: Alan Mackenzie > > > Follow-mode is special in this regard, because with it, showing a > > > partial line is not a flaw, as that same line will be fully visible in > > > the next window, and follow-mode actually switches to that next > > > window. So we need to tell the display engine to behave specially in > > > this case. I suggested 2 ways of doing that, the simple one actually > > > does what you expected, i.e. the force_start flag will win. > > 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. > > 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. > > I propose the following solution: at the critical piece of code in > > follow mode's post-command-hook, follow mode should check > > make-cursor-...-p, and if non-nil, determine, using > > pos-visible-in-window-p whether the cursor is in the last partial line. > > If so, move it one line higher. In follow-mode, the positions of point > > in the non-selected windows are fairly random anyway. > 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) yet still observes the intent of that variable, particularly on the last follow-mode window. > 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. (I can't see how it could be otherwise, except by enhancing the display engine to support multiple windows natively.) > 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). > > As an aside, make-cursor-...-p doesn't appear in either the Emacs manual > > or the Elisp manual, and the documentation for set-window-position > > doesn't mention it. I can feel a documentation writing urge coming on. > We don't document every variable, and this one is unlikely to be > modified from the default. So I see no reason for the urge. 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. -- Alan Mackenzie (Nuremberg, Germany).