From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70386: 30.0.50; (recenter 0 t) does not put point on top of the window Date: Sun, 12 May 2024 09:00:42 +0300 Message-ID: <86eda71sdx.fsf@gnu.org> References: <87v84jrjir.fsf@localhost> <864jc3n510.fsf@gnu.org> <87plurrb2z.fsf@localhost> <86wmoyk3m4.fsf@gnu.org> <86plubw6my.fsf@gnu.org> <87edarf50m.fsf@yahoo.com> <87a5lff2h1.fsf@yahoo.com> <87jzkgaumg.fsf@localhost> <86pltv77w2.fsf@gnu.org> <87a5kz2ze7.fsf@yahoo.com> <87seyotf2v.fsf@localhost> <86msow1bdb.fsf@gnu.org> <87pltsteiu.fsf@localhost> <86le4g19ya.fsf@gnu.org> <87jzk0tcl9.fsf@localhost> <86fruo18pg.fsf@gnu.org> <87h6f4tbbl.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39854"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 12 08:05:04 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s62KW-000A7G-B4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 May 2024 08:05:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s62KA-0006ea-IB; Sun, 12 May 2024 02:04:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s62Jc-0006cD-MT for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 02:04:16 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s62JX-0007tG-5Z for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 02:04:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s62JW-0003aa-Cw for bug-gnu-emacs@gnu.org; Sun, 12 May 2024 02:04: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: Sun, 12 May 2024 06:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70386 X-GNU-PR-Package: emacs Original-Received: via spool by 70386-submit@debbugs.gnu.org id=B70386.171549378513771 (code B ref 70386); Sun, 12 May 2024 06:04:02 +0000 Original-Received: (at 70386) by debbugs.gnu.org; 12 May 2024 06:03:05 +0000 Original-Received: from localhost ([127.0.0.1]:52573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s62Ia-0003a3-GO for submit@debbugs.gnu.org; Sun, 12 May 2024 02:03:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s62IX-0003Zc-ON for 70386@debbugs.gnu.org; Sun, 12 May 2024 02:03:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s62GM-0007LL-QQ; Sun, 12 May 2024 02:00:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=o/uY/B1I0hS/gwKPv8+1TJfdX7cTgSVizDvLwy4w8i0=; b=q2zE11ZCQMIz qk7x802W8lsf3WC82ddK6pxU709yWrMfWc15p4bqyjPKvXpo50OfAOfROaTeY40xNtvOghUON/ZTB BDu70isLdqyt8/0Rfr/dxYMHnnGFt6UfLy4ancqNIttSjXuwe0O2c+ioLHiRM9yz928+jv23B6kCN E2Sovzh3HV5tJIeoskeHJokf3MmuH2DuIP84mCYmz/Crq9pIdeRxetRTMur9fZFR3Bg/25dAOsU8u s0cFjdXCJLpABASvgemBMv0Xws6MQuCxNGn8tNjtUHGUbUtR/jFFWwjXFLRlIGCI+5k30GSrKC+xN 7KKzMe3OxHQkDDg8quCC5A==; In-Reply-To: <87h6f4tbbl.fsf@localhost> (message from Ihor Radchenko on Sat, 11 May 2024 19:09:34 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284891 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, 70386@debbugs.gnu.org > Date: Sat, 11 May 2024 19:09:34 +0000 > > Eli Zaretskii writes: > > >> In my specific reproducer the point is not moved, AFAIK. > > > > Of course it can move: as the window is scrolled by > > pixel-scroll-precision-interpolate, point can become invisible. If > > redisplay kicks in, it will move point to bring it back into the > > viewport. > > But it is not what happens in the recording! > The point remains at the same line. That's only what you see when redisplay shows you something. That's not all that happens. > Or do you mean that the point is somehow moved around during the progn execution? Of course, it does! Even eval-buffer itself moves point. > But it does not look like it is the case - when I try > > (setq point-list nil) > (setq current-line-list nil) > (progn > (push (point) point-list) > (push (count-lines 1 (point)) current-line-list) > (require 'pixel-scroll) > (push (point) point-list) > (push (count-lines 1 (point)) current-line-list) > (pixel-scroll-precision-interpolate > (* -1 (line-pixel-height) > (max 0 (- (count-screen-lines (window-start) (point)) 2))) > nil 1) > (push (point) point-list) > (push (count-lines 1 (point)) current-line-list) > ;; Call original recenter for final adjustment. > (recenter 0 t) > (push (point) point-list) > (push (count-lines 1 (point)) current-line-list)) > > point-list ; -> 757 757 757 757 > current-line-list ; -> 21 21 21 21 Try harder, that's not all the truth. In particular, what happens during the interpolation is not shown. In addition, the way 'recenter' works, it is not guaranteed that point will end up on the line you ask it to place point. It's a "best effort", no more. > > That the behavior changed recently doesn't yet mean the previous > > behavior was correct and the new one is wrong. It might mean your > > code is based on incorrect assumptions, and just happened to work > > previously by sheer luck. > > Maybe. But I do believe that my reproducer demonstrates a bug. Why do you still believe that? What will it take to convince you that in the situation your recipe creates the result can sometimes be not what you want?