Re: Speed up Emacs startup

[Sébastien Vauban]

Hi,

> > Thank you very much for you precise answer but, if I may
> > criticize, I would say your solution has a big drawback
> > regarding "readability" of your configuration file: it's then
> > not clear at all what's loaded by your `.emacs', and you cannot
> > share it on the Web or among colleagues without giving your
> > `loaddefs.el' file if you want the others to benefit from the
> > same functionalities as the ones you have in your environment.
> >
> > That's why a `require' line is still interesting... Do we agree
> > on that?
>
> hum, no, i don't think i agree with you.
>
> environments are different. emacs runs on all different sorts of
> platforms, and there are many different, partly compatible
> emacsen [...].
>
> when you use `require', and the package you are interested in is not
> installed, you get an error at startup. is this the best way to inform
> you, that you have to install this-or-that-package? i think it's
> rather painful: when i move my .emacs to another installation, i
> either would have to install quite some packages, or i'd have to
> comment out or delete several of these `require's.

I've completely avoided that problem by using a `try-require'
function: if the package is not installed, it'll just go on as
if nothing happened.

Of course, the functionality won't be available for that user,
or for me from another station, but it won't hurt, and what's
missing will still be explicitly visible by reading the `.emacs'
source.

    ,----
    | ;; attempt to load a feature/library, failing silently
    | ;; (from Mark Triggs and Damien Elmes)
    |
    | (defun try-require (&rest args)
    |   "Attempt to load a library or module. Return true if all
    | of the libraries given as arguments are successfully
    | loaded"
    |   (if (member nil
    |               (mapcar (lambda (thing)
    |                         (condition-case e
    |                             (if (stringp thing)
    |                                 (load-library thing)
    |                               (require thing))
    |                           (file-error () nil)))
    |                       args))
    |       nil
    |     t))
    `----

If I would spend some time on customizing that function, it
could even tell the user the list of missing packages. Better
can't be.


> before i switched to autoloading, i wanted to make my .emacs portable
> between different machines, and i didn't want to install the full set
> of packages everywhere. so i changed my `require's to
>
>       (require 'feature nil t)
> meaning: if require fails, don't abort with an error.

See "my" above solution.


> one problem remained: when i wanted to modify lists that were defined in
> some package. these lists were not available until the package was
> loaded. this is of course no problem if you `require' the package
> beforehand. i had to do something like this.
>
>       (when (require 'feature nil t)
>         (setq feature-some-var "some string")
>         (add-to-list 'feature-some-list 'some-element))
>
> which with autoloading now looks like this:
>
>       (eval-after-load "feature"
>         '(progn
>            (setq feature-some-var "some string")
>            (add-to-list 'feature-some-list 'some-element)))
>
> that's not much worse. and i can tell which settings belong to which
> package. i don't think that's too bad. and inside these blocks i
> occasionally `require' some subpackages, which is ok here, too.

In my case, it simply is (for example):

    ,----
    | ;; redo the the most recent undo
    | (when (try-require 'redo)
    |   (global-set-key [(shift f11)] 'redo))
    `----

Very explicit and clean, no?


> i only left `require's in my .emacs if the package is either very
> small (browse-killring+), binds a lot of keys (vcursor), i really need
> it every time (ido, session) or if i was just too lazy to update my
> autoloads yet.
>
> tell me if you know other reasons to keep them. 8-)

My only reason to keep the require explicitly in the `.emacs'
configuration file is then, still, the wish of completeness
about what I personally loads when using Emacs on my PC.


> i cut my startup time down from 16s to 4s using autoloads. i think it
> was worth it. 8-)

My only problem is, and therefore you're right, I've still have
to wait 24 seconds for my Emacs to be ready to accept my input...

Hope this is an interesting exchange of points of view!

Best regards,
  Sébastien

-- 
Sébastien Vauban