From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.bugs Subject: bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay Date: Fri, 13 Jun 2014 14:19:21 -0700 Message-ID: <52D781C2-53C8-4994-8B17-D8232D278F94@lawlist.com> References: <83d2ecwv6g.fsf@gnu.org> <83a99gwmwz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1402694424 6715 80.91.229.3 (13 Jun 2014 21:20:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Jun 2014 21:20:24 +0000 (UTC) Cc: 17678@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 13 23:20:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WvYtU-0005VY-Vq for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Jun 2014 23:20:17 +0200 Original-Received: from localhost ([::1]:33234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvYtU-0003Q5-Fx for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Jun 2014 17:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvYtM-0003LJ-Qi for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2014 17:20:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvYtH-0006Ks-Gh for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2014 17:20:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvYtH-0006Ke-E9 for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2014 17:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WvYtG-0008Me-KW for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2014 17:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Keith David Bershatsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2014 21:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17678 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17678-submit@debbugs.gnu.org id=B17678.140269437332096 (code B ref 17678); Fri, 13 Jun 2014 21:20:02 +0000 Original-Received: (at 17678) by debbugs.gnu.org; 13 Jun 2014 21:19:33 +0000 Original-Received: from localhost ([127.0.0.1]:47008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvYsm-0008LV-FX for submit@debbugs.gnu.org; Fri, 13 Jun 2014 17:19:33 -0400 Original-Received: from cobb.liquidweb.com ([50.28.13.150]:47050) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvYsj-0008LD-KH for 17678@debbugs.gnu.org; Fri, 13 Jun 2014 17:19:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=m1Bf6HoEH6aRTrA6oANqtXyCNEOsdL7M0ubIwYoZU88=; b=BECAaLkgnxAAq+5mV6umi1yxyMdVenxuxIy4lo3yiXlz+BHOV7DA4ExeoOy8V739a5PFvSGQ4VmTtLqSDbQFQ8+VHIUUlRzAZ/nBBy/TKWcgOxrBQVsh4jBj2EI06TEP; Original-Received: from cpe-75-85-5-102.socal.res.rr.com ([75.85.5.102]:51488 helo=[192.168.0.4]) by cobb.liquidweb.com with esmtpa (Exim 4.82) (envelope-from ) id 1WvYsY-0002lP-9s; Fri, 13 Jun 2014 17:19:18 -0400 In-Reply-To: <83a99gwmwz.fsf@gnu.org> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cobb.liquidweb.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-Get-Message-Sender-Via: cobb.liquidweb.com: authenticated_id: lawlist/from_h X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90359 Archived-At: The custom minor-mode that I am working places overlays between = `window-start` and `window-end`, and is triggered upon a variety of = occurrences. The three general categories that trigger removal / = placement of overlays are: (1) buffer modification; (2) window = modification; (3) cursor movement. The overlays draw three categories: = (1) end of line indicators (e.g., pilcrow, or single-angle [for cursor = eol]); (2) a horizontal line at the current cursor position that spans = the entire window-width (excluding the line numbers and fringes); and, = (3) a vertical line aligned with the cursor stretching from the top to = bottom of the window (excluding the headline where I have Tabbar). To = make the minor mode as efficient as possible (in terms of time needed to = remove / place the overlays), I am limiting the area to only the visible = window. The goal is to have the new overlays placed before the redisplay occurs = -- this avoids a brief glimpse of the naked buffer once the prior = overlays have been removed (and before the new overlays are laid). = Prior to the existence of the `test-mode` that I sent over a short while = ago (based on the help that you and Stefan have so graciously provided), = I was forcing a redisplay (whenever point moved outside of the *old* = visible window limits) in order to obtain the *new* `window-start` and = *new* `window-end`. It looks as if the `test-mode` concept will resolve = the issue by handling the two different conditions separately -- i.e., = point inside the *old* window limits, versus point outside thereof. --------------------------------------- On Jun 13, 2014, at 1:54 PM, Eli Zaretskii wrote: >> From: Keith David Bershatsky >> Date: Fri, 13 Jun 2014 11:24:01 -0700 >> Cc: 17678@debbugs.gnu.org >>=20 >> I believe splitting up the work between the two hooks may be possible = -- I will need to revise the conditions once I identify additional = situations. As far as I can tell, the `window-scroll-functions` hook is = NOT triggered when `point` STAYS between *old* `window-start` and *old* = `window-end`. So when `point` STAYS between *old* `window-start` and = *old* `window-end`, I will need to use the `post-command-hook`. When = point moves BEYOND *old* `window-start` or `*old* `window-end`, then the = `window-scroll-functions` hook can take over -- with a forced new = `(window-end nil t)`. >=20 > Why do you care about the situation where point stays inside the same > window limits?