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, 16 Jan 2014 13:24:16 +0100 Message-ID: References: <83bnzpu622.fsf@gnu.org> <8338l1t6ip.fsf@gnu.org> <83vbxsb2t6.fsf@gnu.org> <83k3e7br26.fsf@gnu.org> <83eh4b7t8f.fsf@gnu.org> <838uui5y4e.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c80d00767c504f01581bd X-Trace: ger.gmane.org 1389876437 15818 80.91.229.3 (16 Jan 2014 12:47:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 12:47:17 +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 Thu Jan 16 13:47:20 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 1W3mLu-00078F-8c for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 13:47:18 +0100 Original-Received: from localhost ([::1]:60437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLt-0005YJ-Ol for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jan 2014 07:47:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLk-0005Vx-TK for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 07:47:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3mLe-0001Kg-SI for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 07:47:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3mLe-0001KW-PA for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 07:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W3m0L-0003yM-UW for bug-gnu-emacs@gnu.org; Thu, 16 Jan 2014 07:25: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, 16 Jan 2014 12:25: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.138987506315169 (code B ref 16129); Thu, 16 Jan 2014 12:25:01 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 16 Jan 2014 12:24:23 +0000 Original-Received: from localhost ([127.0.0.1]:52940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3lzh-0003wa-Lq for submit@debbugs.gnu.org; Thu, 16 Jan 2014 07:24:22 -0500 Original-Received: from mail-wg0-f51.google.com ([74.125.82.51]:52891) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3lzd-0003wN-FI for 16129@debbugs.gnu.org; Thu, 16 Jan 2014 07:24:18 -0500 Original-Received: by mail-wg0-f51.google.com with SMTP id z12so3109046wgg.30 for <16129@debbugs.gnu.org>; Thu, 16 Jan 2014 04:24:16 -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=+cfVZ+LV0IStn6kpilykJUutBaS2GN2IGwEKIxPQtsI=; b=NnZUPnhmeysE0Y5pNi/+RlKvQr5W5HKo9EgLxafoiHJP7hN+UaX8iXPld446famXLn SxWM1Y254Y7wrMZGGW5ak4Ae+kkmVdCSHcKMWWZ7ASbU+GcNtcA29qS6g0+jftqPwXqt GKmbJWIfidZpFLtZn6udWMQLCLhcqWV/Mrcn4tRfW80lpEpyfdOBpgnnHMscrw4lqS+g CT/uKvI4AiRBlaQyBK28ls8oKDOBb1NK6bWnDzob2mfREOLjTsRmLu8dwuYxAZgw4icV UV3I+NJ5QgZ6dQf4Y2a624AQAP2PX0/5JkhVbImgRj+BBdNqbqiDR/Jl6J5r80dht8ad MrPQ== X-Received: by 10.181.13.165 with SMTP id ez5mr7740104wid.56.1389875056566; Thu, 16 Jan 2014 04:24:16 -0800 (PST) Original-Received: by 10.216.187.199 with HTTP; Thu, 16 Jan 2014 04:24:16 -0800 (PST) In-Reply-To: <838uui5y4e.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:83586 Archived-At: --f46d043c80d00767c504f01581bd Content-Type: text/plain; charset=ISO-8859-1 > > > Basically, it is supposed to do whatever Follow mode does today > > That is not specific enough, especially if you take into consideration > that I have only a vague idea about what Follow mode does. Moreover, > I'm not sure we should ask the display engine do everything it does. > For example, selecting the next/previous window when point moves off > the limits of the current window seems to be something that is easy to > do in Lisp. > > So please do try to come up with a list of requirements that should be > moved to the display engine. I guess setting the window start point > when scrolling would be one; what else? > You're absolutely correct. Most of Follow mode functions could be kept in elisp. In fact, most of them are trivial, take scrolling for example, it simple moves the current window down a suitable amount, and let the post-command hook take care of the rest. As a starting point, I would say that it's main responsibility is to keep the windows aligned, so that one window start where the previous left of. The second thing it should do is that it should "auto select" other windows when, for example, the cursor moved down below the end of the window. In short, do what the post-command-hook does. I will try to give you a deeper description as soon as I can find some time to do it. > > > 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. > > Shouldn't be hard to implement, given some buffer-local variable. > Great. I would suggest that it should be implemented so that the actual test could be written in elisp. In the Follow mode case, the test should be that the buffer is in Follow mode and that it's not the first window. However, I could think of other modes -- one example being Two-column mode, another Scroll all mode -- where this could be useful, but with other criterias. In the simplest form it could be a symbol, nil for "no", t for "yes", and for all other cases call the function it is bound to. Of course, one could make it into a hook, so that more than one mode could have a say, but I think that might be overengineering it a bit... -- Anders --f46d043c80d00767c504f01581bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Basically, it is supposed= to do whatever Follow mode does today

That is not specific enough, especially if you take into consideratio= n
that I have only a vague idea about what Follow mode does. =A0Moreover,
I'm not sure we should ask the display engine do everything it does. For example, selecting the next/previous window when point moves off
the limits of the current window seems to be something that is easy to
do in Lisp.

So please do try to come up with a list of requirements that should be
moved to the display engine. =A0I guess setting the window start point
when scrolling would be one; what else?

You're absolutely correct. Most of Follow mode functions could be kept= in elisp. In fact, most of them are trivial, take scrolling for example, i= t simple moves the current window down a suitable amount, and let the post-= command hook take care of the rest.

As a starting point, I would say that it's main res= ponsibility is to keep the windows aligned, so that one window start where = the previous left of. The second thing it should do is that it should "= ;auto select" other windows when, for example, the cursor moved down b= elow the end of the window.

In short, do what the post-command-hook does.

I will try to give you a deeper description as soon as I ca= n find some time to do it.

=A0
> > I would suggest that we also post feature reque= sts for things that would
> > > help the situation on a shorter time scale. Primarily, I wou= ld 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.

Shouldn't be hard to implement, given some buffer-local variable.=

Great. I would sugg= est that it should be implemented so that the actual test could be written = in elisp. In the Follow mode case, the test should be that the buffer is in= Follow mode and that it's not the first window. However, I could think= of other modes -- one example being Two-column mode, another Scroll all mo= de -- where this could be useful, but with other criterias.

In the simp= lest form it could be a symbol, nil for "no", t for "yes&quo= t;, and for all other cases call the function it is bound to. Of course, on= e could make it into a hook, so that more than one mode could have a say, b= ut I think that might be overengineering it a bit...

=A0 =A0 -- = Anders
--f46d043c80d00767c504f01581bd--