From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: The unwarranted scrolling assumption Date: Fri, 18 Jun 2010 09:29:12 -0400 Message-ID: References: <87631jvpzg.fsf@gmail.com> <4C18211C.3070106@harpegolden.net> <83typ2isns.fsf@gnu.org> <83mxuuicjc.fsf@gnu.org> <83ljadikj1.fsf@gnu.org> <83k4pxijpb.fsf@gnu.org> <83hbl1ihux.fsf@gnu.org> <83631gixa4.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1276867769 756 80.91.229.12 (18 Jun 2010 13:29:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Jun 2010 13:29:29 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Richard Stallman , storm@cua.dk To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 15:29:27 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OPbdO-00052V-Kz for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 15:29:26 +0200 Original-Received: from localhost ([127.0.0.1]:57253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbdO-0003OZ-0u for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 09:29:26 -0400 Original-Received: from [140.186.70.92] (port=43393 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbdH-0003Mh-QT for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:29:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPbdF-0007yk-O8 for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:29:19 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:31795 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPbdC-0007xh-Oi; Fri, 18 Jun 2010 09:29:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEgRG0xLd+Hj/2dsb2JhbACfDnLBbIUbBI0Y X-IronPort-AV: E=Sophos;i="4.53,439,1272859200"; d="scan'208";a="68344890" Original-Received: from 75-119-225-227.dsl.teksavvy.com (HELO pastel.home) ([75.119.225.227]) by ironport2-out.pppoe.ca with ESMTP; 18 Jun 2010 09:29:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 059EA7F26; Fri, 18 Jun 2010 09:29:13 -0400 (EDT) In-Reply-To: (Juanma Barranquero's message of "Fri, 18 Jun 2010 12:15:09 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126149 Archived-At: >>> Stop reading input until it catches its breath. This has two problems, depending on the precise solution used: - if we don't flush the "overflowing input", then this input accumulates, and you end up waiting for your scroll to keep scrolling long after you've stopped pressing the key. - if we do flush the overflowing input, then the user ends up having to be careful not to type too fast, lest Emacs will ignore some of the keys she presses (could be some keys in the middle of a key-sequence). So I don't think it's a good solution. Emacs was designed to handle a slow redisplay by suspending redisplay when it's too slow to avoid the above problems. I think it's a very sound design and don't want to try and change it, because redisplay has always been on the critical path and I don't see that changing in the future. > Which is likely too much work for little gain, so I'm not really > pushing for this to be implemented; fortunately my computer can > currently keep up with scrolling. I think there are several things we can do here: 1 - improve the scrolling behavior such that it doesn't recenter when the user specified that it wants line-by-line scrolling. I hope this thread will find a solution to this problem. 2 - speed up redisplay such that the problem occurs less often. That would be of benefit in many more cases. 3 - Often redisplay is just fast enough except on a few occasions, and some of those occasions are calls to the GC, so making the GC faster or asynchronous would help (i.e. optimize up GC code, make it generational, or concurrent, younameit, but also try and reduce memory allocation to run the GC less often). Stefan