From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Use cases for post-redisplay hooks Date: Tue, 05 Jul 2016 10:45:02 -0700 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by - "") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1467746000 17011 80.91.229.3 (5 Jul 2016 19:13:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 19:13:20 +0000 (UTC) Cc: Michael Heerdegen , =?UTF-8?B?Q2zDqW1l?= =?UTF-8?B?bnQ=?= Pit--Claudel , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 05 21:13:11 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bKVmD-0003gU-Qr for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2016 21:12:57 +0200 Original-Received: from localhost ([::1]:57517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKVmD-0003g7-1g for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2016 15:12:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKUPc-0005Hk-F4 for emacs-devel@gnu.org; Tue, 05 Jul 2016 13:45:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKUPa-0001Xq-7e for emacs-devel@gnu.org; Tue, 05 Jul 2016 13:45:31 -0400 Original-Received: from beige.birch.relay.mailchannels.net ([23.83.209.16]:23424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKUPV-0001W1-1m; Tue, 05 Jul 2016 13:45:25 -0400 X-Sender-Id: _forwarded-from|166.170.48.90 Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1ED01E0883; Tue, 5 Jul 2016 17:45:22 +0000 (UTC) Original-Received: from cobb.liquidweb.com (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id 6833AE01D4; Tue, 5 Jul 2016 17:45:21 +0000 (UTC) X-Sender-Id: _forwarded-from|166.170.48.90 Original-Received: from cobb.liquidweb.com (cobb.liquidweb.com [10.135.9.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.6.15); Tue, 05 Jul 2016 17:45:22 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|166.170.48.90 X-MailChannels-Auth-Id: liquidweb X-MC-Loop-Signature: 1467740721833:3418019852 X-MC-Ingress-Time: 1467740721832 Original-Received: from [166.170.48.90] (port=40931 helo=mb.local.localhost) by cobb.liquidweb.com with esmtp (Exim 4.82) (envelope-from ) id 1bKUPN-00066i-Go; Tue, 05 Jul 2016 13:45:18 -0400 X-AuthUser: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 23.83.209.16 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205198 Archived-At: I can explain it in layman's terms, but I'm not familiar enough with how redisplay works to describe in computer language what happens exactly. [I'm a hobbyist / tinkerer, but do not have any formal training in programming.] I saw that the `window-scroll-functions` hook (hereinafter "WSF") returned correct values for `window-start` and `window-end` in some circumstances, but not all. I saw that the WSF had about two (2) occasions where it is forced to run with a built-in flag, so I borrowed that functionality. The `window-start-end-hook' (hereinafter "WSEH") is kind of like the WSF on steroids. Wherever the WSF would normally be called, the WSEH is also called. I added one (2) additional location for the WSEH to deal with mouse wheel scrolling. I throw the switch on the WSEH every command loop. The WSEH has a check to see if point is fully visible, because that is when `window-start` and `window-end` will not likely change again (so long as the Lisp function attached to the WSEH doesn't alter those value s in any way). When point is fully visible, then the function attached to the WSEH runs and my overlays are placed on the visible window. Keith ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; At Tue, 05 Jul 2016 04:12:30 -0400, Stefan Monnier wrote: > > > The implementation of the `window-start-end-hook` is probably easier to > > explain with a diff, which is attached. > > Hmm... my understanding of the redisplay code is sufficiently fuzzy that > your patch doesn't actually tell me how it's supposed to work. > More specifically the timing is unclear to me: the overlays you add from > your hook affect the display, so you need to run (the bulk of) the > redisplay code *after* running your hook. > > So sounds more like a pre-redisplay-hook. Except that you pre-compute > the expected window-end somehow. > > > Stefan