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: Tue, 14 Jan 2014 13:34:23 +0100 Message-ID: References: <83bnzpu622.fsf@gnu.org> <8338l1t6ip.fsf@gnu.org> <83vbxsb2t6.fsf@gnu.org> <83k3e7br26.fsf@gnu.org> <83eh4b7t8f.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb70b2e8b436804efed6934 X-Trace: ger.gmane.org 1389702922 12294 80.91.229.3 (14 Jan 2014 12:35:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 12:35:22 +0000 (UTC) Cc: 16129@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 14 13:35:28 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 1W33DK-0007od-8C for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jan 2014 13:35:26 +0100 Original-Received: from localhost ([::1]:47849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W33DJ-0003aC-8D for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jan 2014 07:35:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W33D7-0003WC-RR for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2014 07:35:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W33Cy-0000Kh-Ub for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2014 07:35:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W33Cy-0000KY-S0 for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2014 07:35:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W33Cy-0004b5-8w for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2014 07:35: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: Tue, 14 Jan 2014 12:35:04 +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.138970286917592 (code B ref 16129); Tue, 14 Jan 2014 12:35:04 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 14 Jan 2014 12:34:29 +0000 Original-Received: from localhost ([127.0.0.1]:49782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W33CO-0004ZV-3v for submit@debbugs.gnu.org; Tue, 14 Jan 2014 07:34:29 -0500 Original-Received: from mail-we0-f174.google.com ([74.125.82.174]:56804) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W33CK-0004ZI-VY for 16129@debbugs.gnu.org; Tue, 14 Jan 2014 07:34:25 -0500 Original-Received: by mail-we0-f174.google.com with SMTP id x55so313253wes.5 for <16129@debbugs.gnu.org>; Tue, 14 Jan 2014 04:34:24 -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=gtX6r3jmtuiBmvcxDkDK2fUkJG7QvdecR3h3GVAQlqY=; b=B6nN3dka8giC5ji1V4RfhFrb3kajA8lLdB6tCLVJ6O3Yzp0exrSu1JzMNyTw6nD1Rx 7aWrB9evz/hdg62ln5/joOvAmCqcsz7tErtxsonf1slC7BJtHxZE2ODsrTp911DHNS2I MToyx6ING+um5jVzdj1tI+NkpBAD+BmLxJCcaUvsmTmFH7q2vcGpCSB/iczQ5r0byMsh mrHJKwC2eeSADg6EY0+jv5FSBdHkuCMsG7VPCDgyEnlGCQ/N1MknMeJ0FEYooL71MV4O SDE+A1OJb3qTyx/muJtudsGMJbX1T1vcnE0hrWqzNyqxxzvYstF/yjkTUMJ0Xu7TWYCP bUeQ== X-Received: by 10.194.192.233 with SMTP id hj9mr1917498wjc.78.1389702863863; Tue, 14 Jan 2014 04:34:23 -0800 (PST) Original-Received: by 10.216.187.199 with HTTP; Tue, 14 Jan 2014 04:34:23 -0800 (PST) In-Reply-To: <83eh4b7t8f.fsf@gnu.org> 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:83455 Archived-At: --047d7bb70b2e8b436804efed6934 Content-Type: text/plain; charset=ISO-8859-1 > > > Sounds like a good idea to post this feature request. However, being a > > realist, I doubt that this will happen anytime soon. > > You mean, the list of requirements, or their implementation? I hoped > the former should not be too hard to come up with, especially for > someone who is familiar with follow-mode. > I mean the implementation -- adding this to the display engine is a major undertaking. If it gets put on hold, or prove more complicated then anticipated, I think that we can improve the current implementation with a relatively small effort. I think that we can come up with a list of requirements relatively easy. Basically, it is supposed to do whatever Follow mode does today, with a few exceptions (well, right now I can only think of one): * It should be applied to all visible windows where Follow mode is active. (Follow mode today only act upon the selected window -- Mainly for efficiency reasons.) > I would suggest that we also post feature requests for things that would > > help the situation on a shorter time scale. Primarily, I would like to be > > able, on a window-by-window basis, control whether or not a window should > > be recentered, when empty. > > What should Emacs do instead of recentering a window? > It should keep the window empty. Follow mode tries to create the illusion of a combining several windows into one very tall window. When the tail of the buffer doesn't reach the last window(s), for example when you have opened a very small file, follow mode wants the remaining window(s) to be empty. Today, Emacs prevents this by recentering them, breaking the illusion. (This, of course, does not apply to the first window in a sequence of windows, because then you still want the normal recentering.) Follow mode, today, sets the window-start to point-max in those windows whenever it has a chance, to prevent the recentering. Stefan wrote: > The region highlighting > has been moved to Elisp, and it seems that follow-mode's highlighting > code seems to interact poorly with the new behavior. > But the good news is that follow-mode could use the new Elisp > highlighting to "do it right" (no need to use hacks to try and coerce > the redisplay to highlight the region over more than one window). I will look into it the first chance I get! Where is the implementation located, and what interface do I have to make it appear in more than one window? The current Follow mode implementation of getting the highlight region into more than one window stopped working years ago (when Emacs decided that it should only show the region in the selected window). -- Anders --047d7bb70b2e8b436804efed6934 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Sounds like a good idea to post this feature request. However, be= ing a
> realist, I doubt that this will happen anytime soon.

You mean, the list of requirements, or their implementation? =A0I hop= ed
the former should not be too hard to come up with, especially for
someone who is familiar with follow-mode.

I mean the implementation -- adding this to the display engine is a majo= r undertaking. If it gets put on hold, or prove more complicated then antic= ipated, I think that we can improve the current implementation with a relat= ively small effort.

I think that we can come up with a list of requirements= relatively easy. Basically, it is supposed to do whatever Follow mode does= today, with a few exceptions (well, right now I can only think of one):

* It should be applied to all visible windows where Fol= low mode is active. (Follow mode today only act upon the selected window --= Mainly for efficiency reasons.)


> I would suggest that we also post feature requests for things tha= t would
> help the situation on a shorter time scale. Primarily, I would like to= be
> able, on a window-by-window basis, control whether or not a window sho= uld
> be recentered, when empty.

What should Emacs do instead of recentering a window?

It should keep the window empty.

<= div>Follow mode tries to create the illusion of a combining several windows= into one very tall window. When the tail of the buffer doesn't reach t= he last window(s), for example when you have opened a very small file, foll= ow mode wants the remaining window(s) to be empty. Today, Emacs prevents th= is by recentering them, breaking the illusion. (This, of course, does not a= pply to the first window in a sequence of windows, because then you still w= ant the normal recentering.) Follow mode, today, sets the window-start to p= oint-max in those windows whenever it has a chance, to prevent the recenter= ing.

Stefan wrote:
> The region highlighting
> has been moved to Elisp, and it seem= s that follow-mode's highlighting
> code seems= to interact poorly with the new behavior.
> But the good news is that follow-mode could use the n= ew Elisp
> highlighti= ng to "do it right" (no need to use hacks to try and coerce
> the redisplay to highlight= the region over more than one window).

I will look into it the first chance I get! Where= is the implementation located, and what interface do I have to make it app= ear in more than one window?

The current Follow mo= de implementation of getting the highlight region into more than one window= stopped working years ago (when Emacs decided that it should only show the= region in the selected window).

=A0 =A0 -- Anders
--047d7bb70b2e8b436804efed6934--