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#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Date: Thu, 2 Jan 2014 19:39:21 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bf109fea41dfa04ef011cbf X-Trace: ger.gmane.org 1388688013 17054 80.91.229.3 (2 Jan 2014 18:40:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 18:40:13 +0000 (UTC) Cc: 16129@debbugs.gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 02 19:40:19 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 1VynBo-00034k-8i for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 19:40:16 +0100 Original-Received: from localhost ([::1]:46570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VynBn-00069n-O3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 13:40:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VynBf-000687-VY for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 13:40:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VynBb-00005n-4A for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 13:40:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VynBb-0008WJ-0W for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 13:40:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VynBa-0003fG-0Y for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 13:40: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, 02 Jan 2014 18:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16129 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16129-submit@debbugs.gnu.org id=B16129.138868796714027 (code B ref 16129); Thu, 02 Jan 2014 18:40:01 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 2 Jan 2014 18:39:27 +0000 Original-Received: from localhost ([127.0.0.1]:58343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VynB0-0003eA-92 for submit@debbugs.gnu.org; Thu, 02 Jan 2014 13:39:27 -0500 Original-Received: from mail-wg0-f54.google.com ([74.125.82.54]:45993) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VynAx-0003dz-AA for 16129@debbugs.gnu.org; Thu, 02 Jan 2014 13:39:24 -0500 Original-Received: by mail-wg0-f54.google.com with SMTP id n12so12568587wgh.33 for <16129@debbugs.gnu.org>; Thu, 02 Jan 2014 10:39:21 -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=Roxu9Hf1R6LdId3rzaxgHFxNsZIaPsOIVmwtI6PTuko=; b=qN3cVt95gY8AfVmGZEdnNaNYQucriUygfY7ucNNT/GYo1oK4mepDCwkokRNf9MhfIw SqKmaJ8DkDkfYuql5/O1byOgLWhd1pOQBRAflFg8HpxwCw7/H9ShRboUhwykdDmdZxdt EkXWmMU2Drek91y0kOMJ5IaO6flUZ0QQSHWzD6yKHK5Rj35LokMzBl2tq1R9iocIu4EA ljpj7ASo/LK3wF2gBHq1RbDJy19lOIm/Gkp4JnVwH8ZuESMxv8KDFjMNIVD94GkESK8a sI6ixNKpb762pmOcRcENL1WcwsDeF3IMxr6tSZPCX0a5LaV9tfB9TqDlCoNg08ZLPG8A UmQQ== X-Received: by 10.194.108.100 with SMTP id hj4mr5645533wjb.83.1388687961364; Thu, 02 Jan 2014 10:39:21 -0800 (PST) Original-Received: by 10.216.223.140 with HTTP; Thu, 2 Jan 2014 10:39:21 -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:82836 Archived-At: --047d7bf109fea41dfa04ef011cbf Content-Type: text/plain; charset=ISO-8859-1 Hi again! I've dug a bit more into this. It looks like it's not follow-mode that repositions the window, instead I guess it's some kind of recentering code in the display engine that have gone "crazy". I've managed to reproduce the problem with an extremely cut-down version of the code, which simply reads and restores window-start of windows when windows-start is point-max. To reproduce, do the following: emacs -Q Enter and evaluate the following: (defun my-avoid-tail-recenter (&rest _rest) (let* ((orig-buffer (current-buffer)) (top (frame-first-window)) (win top)) ;; If the only window in the frame is a minibuffer ;; window, `next-window' will never find it again... (unless (window-minibuffer-p top) (while (let ((start (window-start win))) (set-buffer (window-buffer win)) (if (eq (point-max) start) ;; Write the same window start back, but don't ;; set the NOFORCE flag. (set-window-start win start)) (setq win (next-window win 'not t)) (not (eq win top)))) ;; Loop while this is true. (set-buffer orig-buffer)))) (add-hook 'post-command-hook 'my-avoid-tail-recenter) C-x 3 M-: (set-window-start (selected-window) (point-max)) RET C-x o C-p Here, the window will be recentered without there being any reason for it. Note that this will apply to any window in any frame, as long as there is a window where window-start == point-max, even if the window displays a different buffer. As this now falls outside of follow-mode, I think that I have reached the end of what I can contribute... Sincerely, Anders Lindgren On Thu, Jan 2, 2014 at 2:55 PM, Anders Lindgren wrote: > Hi again! > > In addition to the problems I originally reported, I realized today that > the modification also made follow-mode place windows incorrectly, which > indicates that some primitive display-related function returns incorrect > values. > > Do you want me to report a new bug, or should we see this as a second > symptom? > > You can verify this by doing the following steps: > > emacs -Q > C-h t > M-> > M-x follow-delete-other-windows-and-split RET > C-p > C-p > > After the second C-p, the left window is recentered, which is shouldn't. > This typically occurs when follow-mode thinks the point is not visible in > any window, which probably is due to incorrect values being reported from > primitive functions. (For example, in bug #15957 `window-end' didn't honour > it's FORCE argument, since some display functions didn't mark the end value > as being dirty.) > > I will try to track this down in more detail. However, I wanted to give > you a heads up since it's appears as though you are close to a release -- > it might take me a couple of days to find the problem, as I have very > limited time to spend on Emacs-related things. > > Sincerely, > Anders Lindgren > > > > On Fri, Dec 13, 2013 at 6:55 PM, Anders Lindgren wrote: > >> Hi! >> >> I agree that we would need to find out why the patch makes Emacs slow. >> (In fact, I only supplied the information about the internals of >> follow-mode to help you track down the problems with the slowdown.) >> >> However, I don't agree with Eli -- it is possible to place window-start >> at point-max! However, there is code in the display engine that explicitly >> recenters such windows, after a while, or when something happens. For >> example: >> >> emacs -Q >> C-x 3 >> C-x o >> M-: (set-window-start (selected-window) (point-max)) RET >> C-x o >> M-< >> blablabla (type some text) >> >> As you type text in the left window at the beginning of the scratch >> buffer, the right window is recentered. Follow-mode needs its windows to >> stay put (even the empty ones), as this is essential in creating the >> illusion that a number of windows make up a very tall virtual window. >> >> When I originally wrote follow-mode (some 18 years ago), I suggested to >> the Emacs maintainers to add a feature to make the recentering of empty >> windows conditional, so that follow-mode could control this. However, at >> the time they were not interested so I continued with the current system, >> which has worked flawlessly since then. >> >> If you are interested in making the change in the display engine, >> follow-mode should of course be rewritten to use it. Otherwise, I suggest >> that we keep it as it is today -- solutions using overlays etc. don't >> appeal to me at all. >> >> -- Anders >> >> >> >> On Fri, Dec 13, 2013 at 5:38 PM, Stefan Monnier > > wrote: >> >>> > I am the original author of follow-mode, so I can share one interesting >>> > implementation detail. When the viewed buffer ends before the last >>> window, >>> > follow-mode tries to display this window without any content (by >>> setting >>> > the window start to point-max). Unfortunately, the Emacs display engine >>> > always tries ensure that windows are not empty so it repositions it... >>> So, >>> > follow-mode hammers in its view of the world every chance it gets, >>> > currrently in post-command hook and window-scroll-functions. >>> >>> Hmm.. so we have 2 things to do: >>> 1- figure out why my patch slowed things down so much. >>> 2- change follow-mode to use a different approach. Maybe a good way is >>> to do the following: put window-point at point-max, and add an overlay >>> on window-start...point-max that makes the text invisible (with >>> a `window' property, so it's only invisible in that window). >>> Of course, maybe that won't work either. But hooking everywhere >>> doesn't sound like a good idea. >>> >>> >>> -- Stefab >>> >> >> > --047d7bf109fea41dfa04ef011cbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi again!

I've dug a bit more into = this. It looks like it's not follow-mode that repositions the window, i= nstead I guess it's some kind of recentering code in the display engine= that have gone "crazy".

I've managed to reproduce the problem with an extre= mely cut-down version of the code, which simply reads and restores window-s= tart of windows when windows-start is point-max.

To reproduce, do the following:

=A0 =A0 emacs -Q
=A0 =A0 Enter and evaluate the following:

(defun my-avoid-tail-recenter (&rest _rest)
=A0 (let* (= (orig-buffer (current-buffer))
(top (frame-first-= window))
(win= top))
=A0 =A0 ;; If the only window in the frame is a minibuffer=
=A0 =A0 ;; window, `next-window' will never find it again...
= =A0 =A0 (unless (window-minibuffer-p top)
=A0 =A0 =A0 (while
=A0(let ((start (= window-start win)))
=A0 =A0(set-buffer= (window-buffer win))
= =A0 =A0(if (eq (point-max) start)
;; Write the same window start back, but don&= #39;t
;; set the NOFORCE= flag.
(set-w= indow-start win start))
=A0 =A0(setq win (next-window win 'not t))
=A0 =A0(not (eq wi= n top)))) =A0;; Loop while this is true.
=A0 =A0 =A0 (set-buffer = orig-buffer))))

(add-hook 'post-command-hook &= #39;my-avoid-tail-recenter)

=A0 =A0 C-x 3
=A0 =A0 M-: (set-window-s= tart (selected-window) (point-max)) RET
=A0 =A0 C-x o
= =A0 =A0 C-p

Here, the window will be recentered wi= thout there being any reason for it.

Note that this will apply to any window in any frame, a= s long as there is a window where window-start =3D=3D point-max, even if th= e window displays a different buffer.

As this now = falls outside of follow-mode, I think that I have reached the end of what I= can contribute...

Sincerely,
=A0 =A0 =A0Anders Lindgren



On Thu, Jan 2, 2014 at 2:55 PM, Anders Lindgren <= ;andlind@gmail.com> wrote:
Hi again!

In addition to the problems I originally reported, I realized today that = the modification also made follow-mode place windows incorrectly, which ind= icates that some primitive display-related function returns incorrect value= s.

Do you want me to report a new bug, or should we see th= is as a second symptom?

You can verify this by doi= ng the following steps:

=A0 =A0 emacs -Q
=A0 =A0 C-h t
=A0 = =A0 M->
=A0 =A0 M-x follow-delete-other-windows-and-split RET<= /div>
=A0 =A0 C-p
=A0 =A0 C-p

After = the second C-p, the left window is recentered, which is shouldn't. This= typically occurs when follow-mode thinks the point is not visible in any w= indow, which probably is due to incorrect values being reported from primit= ive functions. (For example, in bug #15957 `window-end' didn't hono= ur it's FORCE argument, since some display functions didn't mark th= e end value as being dirty.)

I will try to track this down in more detail. However, = I wanted to give you a heads up since it's appears as though you are cl= ose to a release -- it might take me a couple of days to find the problem, = as I have very limited time to spend on Emacs-related things.

Sincerely,
=A0 =A0 Anders Lindgren
=

On Fri, Dec 13, 2013 at 6:55 PM, Anders Li= ndgren <andlind@gmail.com> wrote:
Hi!

I ag= ree that we would need to find out why the patch makes Emacs slow. (In fact= , I only supplied the information about the internals of follow-mode to hel= p you track down the problems with the slowdown.)

However, I don't agree with Eli -- it is possible t= o place window-start at point-max! However, there is code in the display en= gine that explicitly recenters such windows, after a while, or when somethi= ng happens. For example:

=A0 =A0 =A0emacs -Q
=A0 =A0 =A0C-x 3
=A0 =A0 =A0C-x o
=A0 =A0 =A0M-: (set-window-start (selected-win= dow) (point-max)) RET
=A0 =A0 =A0C-x o
=A0 =A0 =A0M-<= ;
=A0 =A0 =A0blablabla =A0 =A0 (type some text)

As you type text in the left window at the beginning of= the scratch buffer, the right window is recentered. Follow-mode needs its = windows to stay put (even the empty ones), as this is essential in creating= the illusion that a number of windows make up a very tall virtual window.<= /div>

When I originally wrote follow-mode (some 18 years ago)= , I suggested to the Emacs maintainers to add a feature to make the recente= ring of empty windows conditional, so that follow-mode could control this. = However, at the time they were not interested so I continued with the curre= nt system, which has worked flawlessly since then.

If you are interested in making the change in the displ= ay engine, follow-mode should of course be rewritten to use it. Otherwise, = I suggest that we keep it as it is today -- solutions using overlays etc. d= on't appeal to me at all.

=A0 =A0 -- Anders



On Fri, Dec 13, 2013 at 5:38 PM, Stefan Monnier <<= a href=3D"mailto:monnier@iro.umontreal.ca" target=3D"_blank">monnier@iro.um= ontreal.ca> wrote:
> I am the original author of follow= -mode, so I can share one interesting
> implementation detail. When the viewed buffer ends before the last win= dow,
> follow-mode tries to display this window without any content (by setti= ng
> the window start to point-max). Unfortunately, the Emacs display engin= e
> always tries ensure that windows are not empty so it repositions= it... So,
> follow-mode hammers in its view of the world every chance it gets,
> currrently in post-command hook and window-scroll-functions.

Hmm.. so we have 2 things to do:
1- figure out why my patch slowed things down so much.
2- change follow-mode to use a different approach. =A0Maybe a good way is =A0 =A0to do the following: put window-point at point-max, and add an overl= ay
=A0 =A0on window-start...point-max that makes the text invisible (with
=A0 =A0a `window' property, so it's only invisible in that window).=
=A0 =A0Of course, maybe that won't work either. =A0But hooking everywhe= re
=A0 =A0doesn't sound like a good idea.


-- Stefab



--047d7bf109fea41dfa04ef011cbf--