help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speeding up Emacs load time


From: Eric Abrahamsen
Subject: Re: Speeding up Emacs load time
Date: Sun, 30 Jun 2013 23:00:16 +0800
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)

Emanuel Berg <embe8573@student.uu.se> writes:

> Rustom Mody <rustompmody@gmail.com> writes:
>
>> The problem is that Emacs invites tinkering with my Elisp
>> settings.  And Elisp is such an imperative language
>> ...
>> And that means that Elisp-hacking means frequent restarts of
>> Emacs.
>
> Say what?! I do Elisp all the time and I *never* restart Emacs.
>
> Why do you have to restart it?
>
> You know about `eval-defun', `eval-last-sexp`, `load-file`, etc.?

Ideally, this works fine. Mostly, it works for smaller libraries you've
written yourself. But try hacking on something larger (org-mode or, god
help you, gnus), and it becomes very, very difficult to make sure you've
cleaned up the run-time. Some vars are read at load time only (so
re-evaling base vars does nothing), and often you succeed only in
eval-ing yourself to a non-working environment. Especially if you're
planning on pushing your changes to some poor unsuspecting group of
users, you need to start from a clean slate.

> For hooks and the like you can simply set them to certain things
> instead of adding (which implies there are stuff there to begin
> with). You can comment out those sections and still eval them when
> needed, so they won't be evaled on init. (This is the only case I
> can think of when writing Elisp would benefit from restarting
> Emacs. I don't know if I'm missing something here.)
>
> And, although Lisp (and Elisp) are a bit "everything goes", not
> really adhering to any paradigm (at least not consistently so),
> which I think is a *good* thing, I still would say Elisp is (if
> anything) functional - imperative/procedural, that's like Basic or
> C (although C obviously is much better, for example the shunned
> goto - what about continue and break in C? Isn't that sort of a
> goto?).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]