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#34038: 26.1; set-window-start sometimes fails to set window start Date: Fri, 11 Jan 2019 21:23:57 +0000 Message-ID: <20190111212357.GA5201@ACM> References: <83sgxzhe04.fsf@gnu.org> <87ef9je67i.fsf@metalevel.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1547242392 26276 195.159.176.226 (11 Jan 2019 21:33:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2019 21:33:12 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 34038@debbugs.gnu.org To: Markus Triska Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 11 22:33:08 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gi4QN-0006el-2u for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2019 22:33:07 +0100 Original-Received: from localhost ([127.0.0.1]:37610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gi4SU-0001br-0z for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2019 16:35:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gi4SF-0001Zk-18 for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2019 16:35:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gi4SD-0007SN-Ul for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2019 16:35:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57109) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gi4SD-0007SI-R5 for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2019 16:35:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gi4SD-0002dm-LM for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2019 16:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jan 2019 21:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34038 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 34038-submit@debbugs.gnu.org id=B34038.154724245310088 (code B ref 34038); Fri, 11 Jan 2019 21:35:01 +0000 Original-Received: (at 34038) by debbugs.gnu.org; 11 Jan 2019 21:34:13 +0000 Original-Received: from localhost ([127.0.0.1]:56390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gi4RR-0002ce-D0 for submit@debbugs.gnu.org; Fri, 11 Jan 2019 16:34:13 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:56953 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gi4RO-0002cT-Kz for 34038@debbugs.gnu.org; Fri, 11 Jan 2019 16:34:12 -0500 Original-Received: (qmail 98178 invoked by uid 3782); 11 Jan 2019 21:34:08 -0000 Original-Received: from acm.muc.de (p2E5D5BCF.dip0.t-ipconnect.de [46.93.91.207]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Jan 2019 22:34:07 +0100 Original-Received: (qmail 5992 invoked by uid 1000); 11 Jan 2019 21:23:57 -0000 Content-Disposition: inline In-Reply-To: <87ef9je67i.fsf@metalevel.at> 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: 209.51.188.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:154364 Archived-At: Hello, Markus. Your original form: (progn (goto-char (point-max)) (insert "\n") (dotimes (x (window-height)) (insert (format "%s\n" x))) (redisplay) (let ((b (buffer-string)) (p (point))) (set-window-start nil p t) (read-key "Please press a key to continue.") (erase-buffer) (insert b) (set-window-start nil p t))) On Fri, Jan 11, 2019 at 13:20:33 +0100, Markus Triska wrote: > Eli Zaretskii writes: > > I think this happens because you call set-window-start with last > > argument non-nil. Doing that tells the display engine that the > > window-start point is just a suggestion, not a hard requirement. > In the documentation of set-window-start, the last argument is described > as: > Optional third arg NOFORCE non-nil inhibits next redisplay from > overriding motion of point in order to display at this exact start. > >From this text, this seems to be precisely what I need: I want to retain > point at this exact place, and I only want to change the window start, > not the point. In my use case, if I set this argument to "nil", then I > get unexpected point motion. Is there a way to reliably set window point > while at the same time preventing motion of point? I tried adding > (redisplay) at strategic places in my code, and this seems to work > somewhat better then, though at the cost of causing display flickering. > Thank you and all the best! > Markus I've played with this for several hours, and my feeling, like yours, is that there's a bug in there, somewhere. If you set scroll-conservatively to a non-zero value, your form behaves properly. This suggests that the problem is in redisplay rather than set-window-start itself. If you remove the erase-buffer and insert forms from the form, (replacing them with an (end-of-buffer)), again you get the desired behaviour. M-: (set-window-start nil (point-max) t) appears to behave correctly. A bit of debugging output shows that after (erase-buffer), window-start is already at 1, not the former point-max. After (insert b), window-start continues to be at 1. erase-buffer and insert are doing something strange with internal display variables. I tried seeing if this was the w->force_start field of the window structure (that's the field which gets set to true when one calls set-window-start _without_ a non-nil NOFORCE, but doesn't get cleared when NOFORCE is non-nil; I think only redisplay clears it). But this isn't it. There might be a clue in the entry for set-window-start in the manual, which says: If NOFORCE is non-`nil', and POSITION would place point off screen at the next redisplay, then redisplay computes a new window-start position that works well with point, and thus POSITION is not used. . This is pure speculation, but perhaps because the entire buffer is currently off the screen, with point being on the empty last line, redisplay is somehow thinking that point is off screen too. If this is the case, it would explain why redisplay scrolls the buffer to put point on the middle window line. -- Alan Mackenzie (Nuremberg, Germany).