[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
Phillip Lord |
Subject: |
Re: Emacs Lisp's future |
Date: |
Wed, 17 Sep 2014 16:10:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: address@hidden (Phillip Lord)
>> Date: Wed, 17 Sep 2014 14:54:22 +0100
>> Cc: address@hidden
>>
>> > - 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
- Re: Emacs Lisp's future, (continued)
Re: Emacs Lisp's future, Phillip Lord, 2014/09/17
- Re: Emacs Lisp's future, Nic Ferrier, 2014/09/17
- Re: Emacs Lisp's future, Stefan Monnier, 2014/09/17
- Re: Emacs Lisp's future, Phillip Lord, 2014/09/17
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/09/17
- Re: Emacs Lisp's future, David Kastrup, 2014/09/17
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/09/17
Re: Emacs Lisp's future,
Phillip Lord <=
performance isn't a concern in ... Emacs Lisp's future, Nic Ferrier, 2014/09/17
Re: performance isn't a concern in ... Emacs Lisp's future, David Kastrup, 2014/09/17
Re: Emacs Lisp's future, Thorsten Jolitz, 2014/09/18
Re: Emacs Lisp's future, Stefan Monnier, 2014/09/17
Re: Emacs Lisp's future, Taylan Ulrich Bayirli/Kammer, 2014/09/17
Re: Emacs Lisp's future, David Kastrup, 2014/09/17
Re: Emacs Lisp's future, Taylan Ulrich Bayirli/Kammer, 2014/09/17
Re: Emacs Lisp's future, Daniel Colascione, 2014/09/17
Re: Emacs Lisp's future, Stefan Monnier, 2014/09/17
Re: Emacs Lisp's future, David Kastrup, 2014/09/17