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: Mon, 15 Apr 2024 19:11:31 +0300 Message-ID: <86wmoyk3m4.fsf@gnu.org> References: <87v84jrjir.fsf@localhost> <864jc3n510.fsf@gnu.org> <87plurrb2z.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23469"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70386@debbugs.gnu.org To: Ihor Radchenko , Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 15 18:13:15 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 1rwOxG-0005vL-Ia for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Apr 2024 18:13:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rwOwy-0007qR-41; Mon, 15 Apr 2024 12:12:56 -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 1rwOwu-0007pm-HU for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 12:12:52 -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 1rwOwu-0007lp-9l for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 12:12:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rwOx6-0007C5-1L for bug-gnu-emacs@gnu.org; Mon, 15 Apr 2024 12:13:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Apr 2024 16:13:04 +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.171319752227177 (code B ref 70386); Mon, 15 Apr 2024 16:13:04 +0000 Original-Received: (at 70386) by debbugs.gnu.org; 15 Apr 2024 16:12:02 +0000 Original-Received: from localhost ([127.0.0.1]:38105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rwOw5-00074B-GE for submit@debbugs.gnu.org; Mon, 15 Apr 2024 12:12:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rwOvy-00072a-GR for 70386@debbugs.gnu.org; Mon, 15 Apr 2024 12:11:59 -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 1rwOvh-0007df-1k; Mon, 15 Apr 2024 12:11:37 -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=QZ8ds4yXADT1gOc5hsru7SEZ2K+hvwOJfY+lKCHyYX8=; b=X0OoUMBUxTld 8jhMQoHb0UYCJ+E+6gMfb/7nNYDDutT32bo8FnnaxVRRtJby9vvGdzutXc6G1ReGWLCQBkaVQO0WN cOjSokigmLVdYmwgUH1qXDPPMGiiHZzWMxUeQ6jt2FjvlJEkWWlhOr0TlfTcft0t4mch9ey3PMwzS BIfsCWZFOI/oIVtOp0BffcOzPOvSt1CLoffT599Pp050Jc+EUZ4dC/kcCRgWoIi9qNWHkOKsWEUbU +k/FjB0mJBM5+TVTL6WTLkDcfN6N/fKLLxIIzFjCq+XmI9GiKYYr+BOQ9fgAVmxLuI2zWTAdsFEL6 POOP85E88gVZPkNJZnPkPg==; In-Reply-To: <87plurrb2z.fsf@localhost> (message from Ihor Radchenko on Sun, 14 Apr 2024 19:36:04 +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:283382 Archived-At: > From: Ihor Radchenko > Cc: 70386@debbugs.gnu.org > Date: Sun, 14 Apr 2024 19:36:04 +0000 > > Eli Zaretskii writes: > > >> 1. emacs -Q > >> 2. Insert the following into scratch buffer and put point at "recenter" > > > > Which "recenter": the one in the comment or the one in (recenter 0 t) ? > > The "(recenter 0 t))" line. > > >> (progn > >> (require 'pixel-scroll) > >> (pixel-scroll-precision-interpolate > >> (* -1 (line-pixel-height) > >> (max 0 (- (count-screen-lines (window-start) (point)) 2))) > >> nil 1) > >> ;; Call original recenter for final adjustment. > >> (recenter 0 t)) > >> > >> 3. M-x eval-buffer > >> 4. Observe that scroll is not set to line 0, despite calling `recenter' > > > > I don't think I understand what you mean by "scroll is not set to line > > 0". Please explain in more detail what you expected to happen (and > > why), and what did happen. > > Expected is as per docstring: > > With a numeric prefix argument ARG, recenter putting point on screen line ARG > relative to the selected window. > > So, I expect that (recenter 0 t) will put the line at point on top of > the window and that (recenter 1 t) will put the line at point at the > second top line. > > My expectation is met when I simply do emacs -Q M-: (recenter 0 t) or > emacs -Q M-: (recenter 1 t) on master. > > Observed: > > 1. Line at point slowly scrolls up until it reaches top of the window > (`pixel-scroll-precision-interpolate' call) > > 2. Line at point is reset back to its initial scroll position > (`recenter' call) What is the "initial scroll position" in this case? > Sometimes, I also observe line at point moving beyond the screen. It's inconsistent in my testing: sometimes works as I'd expect, and sometimes ends up with window's vscroll that is very small: about 1 screen line. Po Lu, could you please look into this? Something in pixel-scroll-precision-interpolate is randomly misbehaving, at least on my system. Since all of this stuff is extremely fragile, it's possible that one of the recent changes in xdisp.c broke it somehow. But the behavior is not consistent, so I wonder what could cause that.