> As the person who brought forth this mildly contentious and somewhat
> silly notion of "byte compiling .emacs", let me just mention that I
> (also) always byte compile packages that I write, and that I think
> _that_ does have a beneficial effect. The compiler will catch things
> like undefined variables & other such bugs that the interpreter
> doesn't catch. 'Pon fixing these, the code is improved.
That's a good point. I think it would be worthwhile to extract an "elisp
check" functionality that does the same/similar checks as byte-compiling but
without actually generating any .elc file. This could be triggered
automatically when saving the .emacs file. We could use it to give guidance
to the user about what kind of code in her .emacs is
obsolete/poor/misguided/...
> The fact that you _shouldn't_ do this in .emacs (now accepted by me, and
> I'm planning on entering a .emacs rehab) sorta/kinda rests on the
> principle that there shouldn't be much code in the .emacs anyway (see
> another recent thread).
It's not so much a question of quantity as a question of how many times it's
executed. Most packages contain functions which are later on executed
potentially repeatedly. Most .emacs files contain mostly one-time commands,
and the few functions defined there are executed fairly rarely (things like
major mode hooks). Speeding up such code is not going to give much benefit,
if any.
Stefan
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
