From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#16431: 24.3.50; `follow-adjust-windows' sometimes fails (patch included) Date: Thu, 16 Jan 2014 16:51:50 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e3d005b33fe04f0186761 X-Trace: ger.gmane.org 1389887619 30371 80.91.229.3 (16 Jan 2014 15:53:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 15:53:39 +0000 (UTC) Cc: 16431-done@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 16 16:53:45 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 1W3pFz-000105-FU for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 16:53:23 +0100 Original-Received: from localhost ([::1]:33453 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3pFz-0000K5-1j for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 10:53:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3pEn-0007B0-2z for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:52:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3pEg-0005sO-LM for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:52:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3pEg-0005sH-Fc for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3pEf-0004iQ-Tm for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 10:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2014 15:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16431 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16431-done@debbugs.gnu.org id=D16431.138988751518112 (code D ref 16431); Thu, 16 Jan 2014 15:52:01 +0000 Original-Received: (at 16431-done) by debbugs.gnu.org; 16 Jan 2014 15:51:55 +0000 Original-Received: from localhost ([127.0.0.1]:53836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3pEY-0004i3-L8 for submit@debbugs.gnu.org; Thu, 16 Jan 2014 10:51:55 -0500 Original-Received: from mail-ob0-f180.google.com ([209.85.214.180]:44397) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3pEV-0004ho-RR for 16431-done@debbugs.gnu.org; Thu, 16 Jan 2014 10:51:52 -0500 Original-Received: by mail-ob0-f180.google.com with SMTP id wm4so2855809obc.25 for <16431-done@debbugs.gnu.org>; Thu, 16 Jan 2014 07:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NkgGCNxMqqdYZ9Gdz4YsXCKtDq6KDyhDd67WRo8lh9I=; b=l4fGSuSjywHzGSa2KvSoT0v7jQR8mnJVVB/rxhmOmvsE19lPdXWxjYxi9otMdQseKO LO9DhVWc0FgIhBLiUUPCzZbmKr1d/fPCaUCOuAlAkkavY0AP3UXkCm3LmGElkyuTPZzV nOZWh/X/k42C8qKAwSGbLrCDp3FJwlEqeqDH46fSQDSOsgSyR7xO9OatgQoKmu1KZUdf NA5rI2imcKw/FRGIs8PU3F184pxP5sgcnKfSr5jaWHryXEWlZUgi73DqMQ/uQ1BfndW+ 3nJTWhvBIfnODQLa0tJSSyEfBHCJah0L1Y9M5bQ7mF2KIA3RFktcjAXrII8FxazRql74 fyIg== X-Received: by 10.60.148.197 with SMTP id tu5mr7453862oeb.11.1389887510750; Thu, 16 Jan 2014 07:51:50 -0800 (PST) Original-Received: by 10.182.114.199 with HTTP; Thu, 16 Jan 2014 07:51:50 -0800 (PST) In-Reply-To: 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:83596 Archived-At: --047d7b2e3d005b33fe04f0186761 Content-Type: text/plain; charset=ISO-8859-1 Hi! > > One thing still seems to be problematic -- `follow-adjust-window' only > work > > properly when `win' is *selected*. > > Indeed, I was tempted to add a (cl-assert (eq win (selected-window))) or > to remove the `win' argument altogether. I didn't do it mostly because > I remembered that we're in feature freeze. > Hmm, but I would qualify that as a bug fix. Besides, you have already changed the signature of `follow-adjust-window', so in some way we are already thumbing on the rules somewhat. > In other words, that I would like to see is the following: > > > (let ((source-pos ....)) > > (with-current-buffer (window-buffer win) > > (goto-char source-pos) > > (follow-adjust-window win))) > > I don't understand why you'd want to compute source-pos while outside of > (window-buffer win). > Oh, I just wanted to show that it came from "the outside" -- it's not really important for the example. Think of this as the location of the "grep hit" or the location which "compile" should present as containing an error. (In my application, it's the location of the current search result of a font-lock rule.) Anyway, the effect that I'm after is that I want the user to walk through a number of locations in a file (again, think of grep hits). As long as the location is visible in one of the side-by-side windows I simply present the location using the overlay arrow and set the window point. Once we have passed beyond the end of the last window I want to reposition the buffer so that the new hit is visible in the middle of the first window -- all this in order to minimize buffer movement. What I want to achieve is that it should be as easy as possible (and future safe) for applications to present a buffer in Follow mode-like sense, even if the buffer is present in a window which isn't selected. > > When windows are aligned, Follow mode does not set the window start or do > > anything else to disturb the redisplay. > > In my suggested approach, when windows are aligned, after each call to > redisplay-window, window-end is cheap (since it was just computed and is > hence marked as up-to-date) and since the windows are already properly > aligned you'd find that window-start does not need to be updated, which > in turn would ensure that the next redisplay-window is also cheap. > > > In this scenario it would definitively help if there were a "window-only > > redisplay" or, even better, a "silent redisplay" that would calculate > where > > the window would end up, but not actually draw anything. (Here, I must > > admit that my knowledge of the display engine is limited.) > > My intention would be for redisplay-window to only update the matrices > (i.e. the internal representation of the rendered window) and let the > subsequent full redisplay deal with updating the display. My > knowledge of the display engine is also limited, but I think such > a redisplay-window function should not be too hard to write. Sounds like a very good idea! Another thing -- you mentioned earlier that the region highlight is nowadays done in elisp, and that it might be possible for Follow mode to make it span multiple windows. Where can I find out more about this? -- Anders --047d7b2e3d005b33fe04f0186761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!
=A0
&g= t; One thing still seems to be problematic -- `follow-adjust-window' on= ly work
> properly when `win' is *selected*.

Indeed, I was tempted to add a (cl-assert (eq win (selected-window)))= or
to remove the `win' argument altogether. =A0I didn't do it mostly b= ecause
I remembered that we're in feature freeze.

Hmm, but I would qualify that as a bug fix. Besides, you have alrea= dy changed the signature of `follow-adjust-window', so in some way we a= re already thumbing on the rules somewhat.

> In other words, that I would like to see is the foll= owing:

> =A0 =A0 =A0 =A0 (let ((source-pos ....))
> =A0 =A0 =A0 =A0 =A0 (with-current-buffer (window-buffer win)
> =A0 =A0 =A0 =A0 =A0 =A0 (goto-char source-pos)
> =A0 =A0 =A0 =A0 =A0 =A0 (follow-adjust-window win)))

I don't understand why you'd want to compute source-pos while= outside of
(window-buffer win).

Oh, I just wanted = to show that it came from "the outside" -- it's not really im= portant for the example. Think of this as the location of the "grep hi= t" or the location which "compile" should present as contain= ing an error. (In my application, it's the location of the current sear= ch result of a font-lock rule.)

Anyway, the effect that I'm after is that I want th= e user to walk through a number of locations in a file (again, think of gre= p hits). As long as the location is visible in one of the side-by-side wind= ows I simply present the location using the overlay arrow and set the windo= w point. Once we have passed beyond the end of the last window I want to re= position the buffer so that the new hit is visible in the middle of the fir= st window -- all this in order to minimize buffer movement.

What I want to achieve is that it should be as easy as = possible (and future safe) for applications to present a buffer in Follow m= ode-like sense, even if the buffer is present in a window which isn't s= elected.

=A0
> When windows are aligned, Follow mode does not set t= he window start or do
> anything else to disturb the redisplay.

In my suggested approach, when windows are aligned, after each call t= o
redisplay-window, window-end is cheap (since it was just computed and is hence marked as up-to-date) and since the windows are already properly
aligned you'd find that window-start does not need to be updated, which=
in turn would ensure that the next redisplay-window is also cheap.

> In this scenario it would definitively help if there were a "wind= ow-only
> redisplay" or, even better, a "silent redisplay" that w= ould calculate where
> the window would end up, but not actually draw anything. (Here, I must=
> admit that my knowledge of the display engine is limited.)

My intention would be for redisplay-window to only update the matrice= s
(i.e. the internal representation of the rendered window) and let the
subsequent full redisplay deal with updating the display. =A0My
knowledge of the display engine is also limited, but I think such
a redisplay-window function should not be too hard to write.

Sounds like a very good idea!

Another thing -- you mentioned earlier that the region highlig= ht is nowadays done in elisp, and that it might be possible for Follow mode= to make it span multiple windows. Where can I find out more about this?

=A0 =A0 -- Anders=A0

--047d7b2e3d005b33fe04f0186761--