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: Fri, 13 Dec 2013 18:55:11 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9cc930ce15e8304ed6e29e1 X-Trace: ger.gmane.org 1386957375 969 80.91.229.3 (13 Dec 2013 17:56:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2013 17:56:15 +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 Fri Dec 13 18:56:20 2013 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 1VrWyJ-00024w-EG for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 18:56:19 +0100 Original-Received: from localhost ([::1]:44088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrWyJ-0004E4-2T for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 12:56:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrWyA-0004DH-GG for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 12:56:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrWy3-0005wF-39 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 12:56:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrWy2-0005wB-W9 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 12:56:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VrWy2-00011C-89 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 12:56: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: Fri, 13 Dec 2013 17:56:02 +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.13869573273874 (code B ref 16129); Fri, 13 Dec 2013 17:56:02 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 13 Dec 2013 17:55:27 +0000 Original-Received: from localhost ([127.0.0.1]:48783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrWxR-00010O-KH for submit@debbugs.gnu.org; Fri, 13 Dec 2013 12:55:26 -0500 Original-Received: from mail-we0-f175.google.com ([74.125.82.175]:56472) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrWxE-0000zz-Gv for 16129@debbugs.gnu.org; Fri, 13 Dec 2013 12:55:20 -0500 Original-Received: by mail-we0-f175.google.com with SMTP id t60so2187984wes.20 for <16129@debbugs.gnu.org>; Fri, 13 Dec 2013 09:55:11 -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=GVW768+wkPHdStcEnim+DogTVSaUbGyXshmMC2vYfVA=; b=HuWVo4UG1d0EJoV/JuhRnhhoy1P+wMVYI09XuBxZLIasynjL5acD7/rkVkkIFxuwCz mKRpYkiZmvRhizMrC7fhjXs5F7p9JsqnwTx7+WT/qpoVuJt2YOWDJwNztG+65cLu1phh tafi7cWieP7UHLbPV0FNqbtcKX3YhIfJOXiNGF5HEOiF8V4W/GiuwXn4f3FEEhltjBO4 5Aq/SxoTJd0Mn1r6t/k6Goec5BQwL+zyBfOLggX3v7C8D350lglSd3b570emumId5J0i f9oVMn8gu5N4jPWMOPD39SzfCnhHguIfmJlNK3l+uDSqJxTsCz9hV5i9R0SMsZqVRoHi 5KjQ== X-Received: by 10.180.79.67 with SMTP id h3mr3554621wix.58.1386957311662; Fri, 13 Dec 2013 09:55:11 -0800 (PST) Original-Received: by 10.216.223.140 with HTTP; Fri, 13 Dec 2013 09:55:11 -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:81898 Archived-At: --14dae9cc930ce15e8304ed6e29e1 Content-Type: text/plain; charset=ISO-8859-1 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 > --14dae9cc930ce15e8304ed6e29e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

I agree that we would need to find = out why the patch makes Emacs slow. (In fact, I only supplied the informati= on about the internals of follow-mode to help you track down the problems w= ith 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 <monnier@iro.umontreal.ca> wrote:
> I am the original aut= hor 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

--14dae9cc930ce15e8304ed6e29e1--