From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.bugs Subject: bug#18618: 25.0.50; `window-end win t` produces erroenous result with `window-scroll-functions` hook. Date: Fri, 28 May 2021 23:16:41 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7176"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 18618@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 29 08:17:30 2021 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 1lmsHp-0001ec-Td for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 08:17:30 +0200 Original-Received: from localhost ([::1]:36102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmsHn-0003jC-RT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 May 2021 02:17:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmsHO-0003io-T2 for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 02:17:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmsHO-0003et-J1 for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 02:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lmsHO-0000vu-DC for bug-gnu-emacs@gnu.org; Sat, 29 May 2021 02:17:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Keith David Bershatsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 May 2021 06:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18618 X-GNU-PR-Package: emacs Original-Received: via spool by 18618-submit@debbugs.gnu.org id=B18618.16222690072867 (code B ref 18618); Sat, 29 May 2021 06:17:02 +0000 Original-Received: (at 18618) by debbugs.gnu.org; 29 May 2021 06:16:47 +0000 Original-Received: from localhost ([127.0.0.1]:55820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmsH9-0000jn-EX for submit@debbugs.gnu.org; Sat, 29 May 2021 02:16:47 -0400 Original-Received: from gateway23.websitewelcome.com ([192.185.50.185]:48753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmsH7-0000hM-0q for 18618@debbugs.gnu.org; Sat, 29 May 2021 02:16:46 -0400 Original-Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 651AC3C24 for <18618@debbugs.gnu.org>; Sat, 29 May 2021 01:16:44 -0500 (CDT) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id msH5lR68qMGeEmsH6lNAHx; Sat, 29 May 2021 01:16:44 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:Cc:To:From:Message-ID:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JqsopWoi1HUa8PzTNQAdrp8J4LFhP/YcUfU8k1ZHE7A=; b=cgCU6jI72o49YetH58ezDznURP h7g2s9LQTQ/9GYRbtZ9WDGJKU1oBe86MgUFkec+C6AQEZcEgg1UN2eJQZefZ+kMj6VGxAQS0/WWED AAvpT7C7f6v2RolWm2hERRbQLSOAglNPGJlZeN83ZQAGVao65iM4jTUEI/HU/4GkMRDp2HRvg9fh/ U6cnq/P0SF4xec92v6qqb7mWAJxtUGNSlsA6K+4E1nE+lZRBVrDIR9k7LZHpLkUmUBlmJlQYcBFRh AMHC6HAwh5sXUbFQ9rqVg/7tor3tXKEANNCK6sbpdwN+tMlLwUlkdeXNdUQXze5INsfLjAgsg2vOY 4WvixdRA==; Original-Received: from cpe-45-48-245-70.socal.res.rr.com ([45.48.245.70]:57862 helo=mp-capitan.local) by gator3053.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lmsH5-004Imk-KI; Sat, 29 May 2021 01:16:43 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.245.70 X-Source-L: No X-Exim-ID: 1lmsH5-004Imk-KI X-Source-Sender: cpe-45-48-245-70.socal.res.rr.com (mp-capitan.local) [45.48.245.70]:57862 X-Source-Auth: lawlist X-Email-Count: 2 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes 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" Xref: news.gmane.io gmane.emacs.bugs:207503 Archived-At: Lars: I haven't played in depth with the Emacs internals for a couple of years or so. In working on my own feature requests (back in the day), I learned that window-start/end cannot be accurately ascertained with 100% certainty until the tail end of redisplay ... If a user were to add/remove something with Lisp, then redisplay would need to recalculate to take that modification into consideration -- necessitating further recalculation, which may alter window-start/end. In terms of my own feature requests, I opted to use `update_window` in dispnew.c to add visual modifications to the glass that did not alter any text or points in the buffer. That way, no further calculation was needed as to window-start/end points -- as said points were "final" calculations at that late stage of redisplay. The `window-scroll-functions` hook only operates under certain criteria, but not all the time. As of my last look a couple of years ago, there was no hook that operated towards the latter part of redisplay with 100% certainty. For a few years before using `update_window`, I used a combination of the `post-command-hook` and the `window-scroll-functions` hook to try and catch the majority of situations to ascertain window-start/end, but there were always several situa tions where the two hooks where insufficient ... An example of what users were required to do back in the day can be seen by examining libraries such as the deprecated linum-mode, which used both o f the aforementioned hooks because there is/was no sole hook that could accurately predict window-start/end with 100% certainty. Keith ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > Date: [05-28-2021 20:37:18] <29 May 2021 05:37:18 +0200> > From: Lars Ingebrigtsen > To: Keith David Bershatsky > Cc: 18618@debbugs.gnu.org > Subject: Re: bug#18618: 25.0.50; `window-end win t` produces erroenous result with `window-scroll-functions` hook. > > Keith David Bershatsky writes: > > > Steps to reproduce the issue. > > > > 1. Create a function that reports (e.g., a message) the value of `(window-end win t)` and attach that function to the `window-scroll-functions` hook. > > > > 2. Open a long file in either fundamental-mode or text-mode. > > > > 3. M-x end-of-buffer > > > > 4. M-x beginning-of-buffer > > > > The result of step 4 reports an erroneous window-end value that is at > > the very end of the buffer, instead of the correct window-end (i.e., > > which is much closer to the beginning of the buffer). > > (I'm going through old bug reports that unfortunately got no response at > the time.) > > This problem is still present in Emacs 28. Here's an easier test case: > > (defun foo (win _) > (message "End: %s" (window-end win t)) > nil) > (push 'foo window-scroll-functions) > > This reports the same number in both 3) and 4) when transient-mark-mode > is switched on, but not when it's off. It's also correct if that mode > is on, and the region is active. > > I haven't tried to debug further -- perhaps it's immediately obvious to > somebody what could be causing this glitch? > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no