From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 16:10:40 +0100 Message-ID: <871traxoy7.fsf@newcastle.ac.uk> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <87egvaxshd.fsf@newcastle.ac.uk> <83k3522ulo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410966682 25437 80.91.229.3 (17 Sep 2014 15:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 15:11:22 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 17:11:15 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XUGt1-0000Zt-45 for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 17:11:15 +0200 Original-Received: from localhost ([::1]:45580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGt0-0006PG-Ma for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 11:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGsl-0006PB-9q for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:11:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUGsg-0002rI-FU for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:10:59 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:39223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGsX-0002q6-QC; Wed, 17 Sep 2014 11:10:46 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1XUGsU-0007Zj-D6; Wed, 17 Sep 2014 16:10:42 +0100 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XUGsT-0001Gh-4R; Wed, 17 Sep 2014 16:10:41 +0100 In-Reply-To: <83k3522ulo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 17 Sep 2014 17:24:19 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174437 Archived-At: Eli Zaretskii writes: >> From: phillip.lord@newcastle.ac.uk (Phillip Lord) >> Date: Wed, 17 Sep 2014 14:54:22 +0100 >> Cc: emacs-devel@gnu.org >> >> > - machines still did get faster over the last 10 years (much less so >> > than over the preceding 10 years, but also probably much more so than >> > over the next 10 years). >> >> Well, Emacs is a text editor. The CPU demands of the task haven't >> increased that much over the last 10 years either. > > You are wrong here. Emacs 23 added many CPU-intensive features, like > visual-line-mode. Emacs 24 added bidirectional display, which makes > redisplay need roughly twice as much juice as Emacs 23 needed. And > these are only two examples that pop up in my head after a 3-sec > thought; I'm sure there are more. > > So it's not like we use up every additional CPU cycle the chips are > giving us, but we are certainly using significantly more than we did > 10 years ago. What can I say? I don't sit around waiting for emacs to do stuff nowadays when I am using it. And I've just implemented a package that copies, then searches and replaces an entire buffer on every keypress. And I don't notice it running for moderate size files. The manual talks about the performance danger of overlay, but I've just put an overlay an every word in a 300 line buffer, and I can't notice that either. Even though Emacs now takes considerably more than Eight Megabytes, it is not Constantly Swapping. CPU has grown quicker than Emacs demands. Phil