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 20:25:46 +0000 Message-ID: <20180929202545.GE5008@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> <20180929144846.GC5008@ACM> <83k1n45onn.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 1538253020 18823 195.159.176.226 (29 Sep 2018 20:30:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 20:30:20 +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 22:30:15 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 1g6LsS-0004iY-8Q for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 22:30:12 +0200 Original-Received: from localhost ([::1]:52535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6LuY-0002VO-TW for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 16:32:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6LuH-0002Tm-C1 for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 16:32:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6LuE-0003w6-2w for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 16:32:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54953) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6LuD-0003vu-Ue for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 16:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6LuD-0000Vh-Lb for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 16:32: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 20:32: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.15382530821907 (code B ref 32848); Sat, 29 Sep 2018 20:32:01 +0000 Original-Received: (at 32848) by debbugs.gnu.org; 29 Sep 2018 20:31:22 +0000 Original-Received: from localhost ([127.0.0.1]:59211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6Lta-0000Uh-EC for submit@debbugs.gnu.org; Sat, 29 Sep 2018 16:31:22 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:24150 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1g6LtY-0000UX-Ki for 32848@debbugs.gnu.org; Sat, 29 Sep 2018 16:31:21 -0400 Original-Received: (qmail 20835 invoked by uid 3782); 29 Sep 2018 20:31: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 22:31:17 +0200 Original-Received: (qmail 19385 invoked by uid 1000); 29 Sep 2018 20:25:46 -0000 Content-Disposition: inline In-Reply-To: <83k1n45onn.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:150771 Archived-At: Hello, Eli. On Sat, Sep 29, 2018 at 18:06:20 +0300, Eli Zaretskii wrote: > > 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? Yes. But point in the non-selected windows of a follow set is in any case of no consequence. Try setting up follow mode, do a few things in it, then do C-x o. Often, when I do this, point is at the mid point of the window moved to. Of no consequence. What I, as a typical user (hah!), sees, is that point moves from the LH window to the RH window. If I were using the GUI version, I would soon learn not to see the hollowed out representation of point left in the "old" window. Maybe we could enhance Emacs to be able not to display this hollow point in the non selected windows of a follow set. I've not looked into it, but it shouldn't be too difficult. If we had real support for a multiple window in the display engine (I started trying to write this a couple of years ago, but didn't get very far), there would be just one point shared by all the "sub"windows, and a single full width mode line rather than a truncated mode line for each "sub"window. Maybe somebody will someday construct this. > > > 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. Oh, OK, then! I can accept this. > > It can't be difficult, just > > creating a buffer local variable and setting it to nil. ;-) > Right. I will make this change to follow-mode for Emacs-26, and commit it with a "don't merge to master" instruction to our infrastructure. Probably tomorrow. > > > 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. OK, let's do it! What arguments will such a function get? I think a single argument, a window, would be appropriate. The function would then return either nil (for most windows) or non-nil (for a "right most" window). > > 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. You may be right. But I think I'll extend the docu anyway. Thanks! -- Alan Mackenzie (Nuremberg, Germany).