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: Mon, 13 Jan 2014 12:41:14 +0100 Message-ID: References: <83bnzpu622.fsf@gnu.org> <8338l1t6ip.fsf@gnu.org> <83vbxsb2t6.fsf@gnu.org> <83k3e7br26.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb70b2e9b6ad904efd88d31 X-Trace: ger.gmane.org 1389613331 11056 80.91.229.3 (13 Jan 2014 11:42:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jan 2014 11:42:11 +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 Mon Jan 13 12:42:17 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 1W2fuJ-0005cd-1R for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Jan 2014 12:42:15 +0100 Original-Received: from localhost ([::1]:41923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2fuI-0003eL-NZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Jan 2014 06:42:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2fuB-0003e5-Dl for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2014 06:42:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2fu7-00040z-35 for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2014 06:42:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2fu6-00040v-VZ for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2014 06:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W2fu5-0006tK-VU for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2014 06:42: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: Mon, 13 Jan 2014 11:42: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.138961328226420 (code B ref 16129); Mon, 13 Jan 2014 11:42:01 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 13 Jan 2014 11:41:22 +0000 Original-Received: from localhost ([127.0.0.1]:48508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2ftR-0006s1-VK for submit@debbugs.gnu.org; Mon, 13 Jan 2014 06:41:22 -0500 Original-Received: from mail-wi0-f180.google.com ([209.85.212.180]:57964) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W2ftL-0006rm-G5 for 16129@debbugs.gnu.org; Mon, 13 Jan 2014 06:41:20 -0500 Original-Received: by mail-wi0-f180.google.com with SMTP id d13so586569wiw.7 for <16129@debbugs.gnu.org>; Mon, 13 Jan 2014 03:41:14 -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=5NaLncg+AIlVqdVV5RJ5nvrejNXmBU16hOuE3r4phhs=; b=hmEDv3YNquxvho/tXGlyww1EBfOb3i1SdkVwoofoUtibGzEwF1YRxGs43QxH/5Qvq8 69N813qmT9SKReWPhPGMghAttkYUm5fmlhIL8fVCGRwVM5isnvCVzmaUje+Pu7K1ZSYt nFsrj6OoaXjmq1JvyADSoJO/GTBMDqaOOweNLjuySV8iJrYHIrlyubxhA6iTaiuRfZKf abyzwJ/u5ozdI0sN4zydyxnETLvhjIsmRZEir4BcwufijGFzMCt6d5PAdXEEKQxilEw/ hS8tu1mDt3RFxsiGCBVIw0IFr8UhIPE465d6aEVJlbAaVro3MAC93zi0duidpFqEooEb 8pJA== X-Received: by 10.194.192.233 with SMTP id hj9mr2348822wjc.78.1389613274587; Mon, 13 Jan 2014 03:41:14 -0800 (PST) Original-Received: by 10.216.187.199 with HTTP; Mon, 13 Jan 2014 03:41:14 -0800 (PST) In-Reply-To: <83k3e7br26.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:83396 Archived-At: --047d7bb70b2e9b6ad904efd88d31 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. 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. Also, we might look into the speed issues, we might be able to avoid double redraws with little effort, for the common cases. While I'm at it. I updated to the latest trunk today and saw that cursor movements are a lot faster now, including the when the tail is showing. However, I noticed that when the region is active, the region highlight is not updated as fast as it is when follow-mode is off, when running the cursor. -- Anders On Fri, Jan 10, 2014 at 8:00 PM, Eli Zaretskii wrote: > > Date: Fri, 10 Jan 2014 19:52:18 +0100 > > From: Anders Lindgren > > Cc: Stefan Monnier , 16129@debbugs.gnu.org > > > > Concretely, how do we proceed from here? I don't have the necessary > > knowledge of the internals of the display engine and I don't have much > time > > to spend on a major rewrite like this. However, if someone decides to > > proceed with this, I will try to support them as much that I can. > > I suggest to file a separate feature request bug report about this, > and include in it the requirements for the display engine to support > follow-mode. That is, given a set of windows that are "following" > each other, what should redisplay do when certain display-related > events happen. Then interested volunteers can implement that. > --047d7bb70b2e9b6ad904efd88d31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sounds like a good idea to post this feature request. Howe= ver, being a realist, I doubt that this will happen anytime soon.

<= /div>
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 s= hould be recentered, when empty. Also, we might look into the speed issues,= we might be able to avoid double redraws with little effort, for the commo= n cases.

While I'm at it. I updated to the latest trunk toda= y and saw that cursor movements are a lot faster now, including the when th= e tail is showing. However, I noticed that when the region is active, the r= egion highlight is not updated as fast as it is when follow-mode is off, wh= en running the cursor.

=A0 =A0 -- Anders


On Fri, Jan 10, 2014 at 8:00 PM, Eli Za= retskii <eliz@gnu.org> wrote:
> Date: Fri, 10 Jan 2014 19:52:18 +0100 > From: Anders Lindgren <andlind= @gmail.com>
> Cc: Stefan Monnier <mon= nier@iro.umontreal.ca>, 161= 29@debbugs.gnu.org
>
> Concretely, how do we proceed from here? I don't have the necessar= y
> knowledge of the internals of the display engine and I don't have = much time
> to spend on a major rewrite like this. However, if someone decides to<= br> > proceed with this, I will try to support them as much that I can.

I suggest to file a separate feature request bug report about this, and include in it the requirements for the display engine to support
follow-mode. =A0That is, given a set of windows that are "following&qu= ot;
each other, what should redisplay do when certain display-related
events happen. =A0Then interested volunteers can implement that.

--047d7bb70b2e9b6ad904efd88d31--