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 14:55:59 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01493de0410df904eefd27db X-Trace: ger.gmane.org 1388671038 13471 80.91.229.3 (2 Jan 2014 13:57:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 13:57:18 +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 14:57:22 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 1Vyim0-0004Zl-4o for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 14:57:20 +0100 Original-Received: from localhost ([::1]:45145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyilz-0002ug-Sd for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 08:57:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyilr-0002uW-7G for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 08:57:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vyilm-00058i-9R for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 08:57:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyilm-00058X-5k for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 08:57:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vyilk-0003hi-1D for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 08:57:04 -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 13:57:03 +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.138867097014165 (code B ref 16129); Thu, 02 Jan 2014 13:57:03 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 2 Jan 2014 13:56:10 +0000 Original-Received: from localhost ([127.0.0.1]:57563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vyikq-0003gM-Fr for submit@debbugs.gnu.org; Thu, 02 Jan 2014 08:56:09 -0500 Original-Received: from mail-we0-f172.google.com ([74.125.82.172]:49734) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vyiki-0003g0-L5 for 16129@debbugs.gnu.org; Thu, 02 Jan 2014 08:56:01 -0500 Original-Received: by mail-we0-f172.google.com with SMTP id p61so12650332wes.17 for <16129@debbugs.gnu.org>; Thu, 02 Jan 2014 05:55:59 -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=/snguPO+QrWuPPIJddSVE+qUJRSlmRTxbObRLrr6WMQ=; b=sc57Pxm2gz4AP2Ef/ZSCbRVYCl9pqAedHT3OLA4nIJ6aegr9b3p7AsawRH1ogzYwOl kMqcetRrtNHW++/Plc7YfnN4nSSMu5B6BZ0y8GP1MWBGLgYyUwBcFXQFuiTar4UtZ2Mm a/LIUHwcvmR5RfdqBbNZ8RzpUnm5IF4rBtLJ/cvmn2mkBo/RHUBwj5aFwBZVRAJH0OdU AK8H7DMd/tEM8oxubQL8ZkU81utIW+EbPB4Tk/H6PdE2G8/KZjl8lvxcPWkbsllLnPpM SrncQIACe38QTdbGhvIJb1/tu2DtPs4Vl7qbxkAhstSYVqekqtTRTb3ZFmbkvqWMdPJF skug== X-Received: by 10.194.236.9 with SMTP id uq9mr45133752wjc.31.1388670959552; Thu, 02 Jan 2014 05:55:59 -0800 (PST) Original-Received: by 10.216.223.140 with HTTP; Thu, 2 Jan 2014 05:55:59 -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:82828 Archived-At: --089e01493de0410df904eefd27db Content-Type: text/plain; charset=ISO-8859-1 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 >> > > --089e01493de0410df904eefd27db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi again!

In addition to the problems I= originally reported, I realized today that the modification also made foll= ow-mode place windows incorrectly, which indicates that some primitive disp= lay-related function returns incorrect values.

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 Lindgren <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

<= br>
On Fri, Dec 13, 2013 at 5:38 PM, Stefan M= onnier <monnier@iro.umontreal.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


--089e01493de0410df904eefd27db--