From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chad Brown Newsgroups: gmane.emacs.devel Subject: Re: The unwarranted scrolling assumption Date: Thu, 17 Jun 2010 13:39:43 -0700 Message-ID: <6028D686-A84E-4DA2-B4BC-A9F345FED07C@mit.edu> References: <87ocfcj7r4.fsf@mail.jurta.org> <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> <87k4pxpg6q.fsf@engster.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1276807204 14502 80.91.229.12 (17 Jun 2010 20:40:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 20:40:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 17 22:39:59 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 1OPLsU-0000m2-H0 for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 22:39:58 +0200 Original-Received: from localhost ([127.0.0.1]:60829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPLsS-0001oC-Tg for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 16:39:56 -0400 Original-Received: from [140.186.70.92] (port=36280 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPLsL-0001mq-R3 for emacs-devel@gnu.org; Thu, 17 Jun 2010 16:39:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPLsK-0002y1-FB for emacs-devel@gnu.org; Thu, 17 Jun 2010 16:39:49 -0400 Original-Received: from dmz-mailsec-scanner-7.mit.edu ([18.7.68.36]:65161) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPLsK-0002xu-Db for emacs-devel@gnu.org; Thu, 17 Jun 2010 16:39:48 -0400 X-AuditID: 12074424-b7c30ae000000a22-27-4c1a8813864b Original-Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 2F.9C.02594.3188A1C4; Thu, 17 Jun 2010 16:39:48 -0400 (EDT) Original-Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o5HKdlow011799; Thu, 17 Jun 2010 16:39:47 -0400 Original-Received: from [10.0.1.6] (c-98-247-149-76.hsd1.wa.comcast.net [98.247.149.76]) (authenticated bits=0) (User authenticated as yandros@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o5HKdiJI015865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jun 2010 16:39:46 -0400 (EDT) In-Reply-To: <87k4pxpg6q.fsf@engster.org> X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:126099 Archived-At: On Jun 17, 2010, at 1:17 PM, David Engster wrote: >> It doesn't jump for me. And, if the machine is too slow and cannot >> keep up with the keyboard's autorepeat rate, then what's wrong with >> the "jumps"? What would you want Emacs to do instead, if it cannot >> keep up with the input? >=20 > Well, you got a point there. I remember that for some time I simply = used > something like > [...] >=20 > What I would like is that the input is somehow limited to Emacs' > speed, but maybe this simply isn't possible? This is the question I was trying to ask Lennart also, and I'm glad to = see both progress on an improvement and a return to the core question. As=20= I understand your answer, you're suggesting that somehow users not be=20 able to press the down key faster than emacs can scroll, which seems=20 like a non-starter to me. =20 Many of these systems were first designed in the days where people would=20= set a baud rate for the terminal connecting to the machine running = emacs, and then refined or replaced over time. I doubt many people still use = emacs via a vt100 and a 1400 baud modem (as I once did regularly), but = especially in the era of netbooks and smartphones, we can't expect the display = system=20 to *always* be faster than the user. Speeding up in the normal cases = (like I=20 assume yours and Lennart's) of a relatively fast local machine is a = great goal, but we do have to plan for some method of dealing with `slow' systems = also. It is almost certainly possible to add a heuristic method for emacs to = throw throw away input if it gets too far ahead of redisplay, although those = code=20 paths seem pretty seriously forbidding to me. Would this be better? = Would you want it to throw away all further input, or just scrolling? It = seems hard to=20 imagine a situation in which you'd want to throw away scrolling and yet = keep text-modifying commands without somehow recognizing absolute-movement commands (like end-of-buffer), but for that to work you need a lookahead = into=20 the input stream. Such systems would need to be optional, and you'd = probably=20 really want a way for emacs to indicate that it had thrown away some of = your input (although maybe you could dispense with that if you could convince=20= your heuristic that the `middle' scrolling was a no-op). Hope this helps, *Chad