From: "Sébastien Vauban" <ewgeocaufsfb@spammotel.com>
Subject: Re: Speed up Emacs startup
Date: Tue, 22 Nov 2005 17:39:17 +0100 [thread overview]
Message-ID: <uoe4cprgq.fsf@missioncriticalit.com> (raw)
In-Reply-To: 87psosrcyh.wl@nospam.anselm.chemie.fu-berlin.de
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
next prev parent reply other threads:[~2005-11-22 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.14537.1131532545.20277.help-gnu-emacs@gnu.org>
2005-11-09 17:05 ` List of major modes? rgb
2005-11-22 8:39 ` Speed up Emacs startup Sébastien Vauban
2005-11-22 11:19 ` Anselm Helbig
2005-11-22 12:56 ` Sébastien Vauban
2005-11-22 14:09 ` Anselm Helbig
2005-11-22 16:39 ` Sébastien Vauban [this message]
2005-11-23 0:07 ` Anselm Helbig
2005-11-23 8:59 ` Ismael Valladolid Torres
[not found] ` <mailman.16441.1132736439.20277.help-gnu-emacs@gnu.org>
2005-11-24 10:03 ` Jason Rumney
2005-11-25 4:26 ` Stefan Monnier
2005-11-22 14:18 ` Lennart Borgman
2005-11-22 20:11 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uoe4cprgq.fsf@missioncriticalit.com \
--to=ewgeocaufsfb@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).