How to Reduce Emacs Load Time

How to Reduce Emacs Load Time

[formido]

Hello there,

Emacs takes like 10 seconds to load. It's a lot faster if I don't load
all my packages. What strategies could I use to get my load time down?
Emacs itself is made up of tons of elisp files and it doesn't take
forever to load, so I don't see why I should be forced to endure long
load times just because I add third party packages. If I do, 'require
package', I'm at the mercy of the package maker's initialization
process, right?

Re: How to Reduce Emacs Load Time

[Pascal J. Bourguignon]

formido <formido@gmail.com> writes:

> Hello there,
>
> Emacs takes like 10 seconds to load. It's a lot faster if I don't load
> all my packages. What strategies could I use to get my load time down?
> Emacs itself is made up of tons of elisp files and it doesn't take
> forever to load, so I don't see why I should be forced to endure long
> load times just because I add third party packages. If I do, 'require
> package', I'm at the mercy of the package maker's initialization
> process, right?

Right.

- compile ~/.emacs ; this is not a good idea, because the gain is
  minimal, and you have to remember compiling it everytime you update
  ~/.emacs.

- don't load what you don't need.  Remove cruft from your ~/.emacs.

- don't load what you need, yet.  This means, instead of loading or
  requiring the packages you may need, define autoloading functions.
  Good packages will do that for you, when you require them, they load
  only a file which defines autoloading functions, so you spend time
  loading the package only when you try to run these functions.

- load everything, in advance.  And save a new emacs image, then boot
  that emacs image instead of the empty standard one.  It's not as
  easy to do in emacs than in Common Lisp implementations, but it's
  possible.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.

Re: How to Reduce Emacs Load Time

[formido]

On Aug 30, 3:05 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> formido <form...@gmail.com> writes:
> > Hello there,
>
> > Emacs takes like 10 seconds to load. It's a lot faster if I don't load
> > all my packages. What strategies could I use to get my load time down?
> > Emacs itself is made up of tons of elisp files and it doesn't take
> > forever to load, so I don't see why I should be forced to endure long
> > load times just because I add third party packages. If I do, 'require
> > package', I'm at the mercy of the package maker's initialization
> > process, right?
>
> Ah, also even it emacs took one hour to load, it woudn't matter much,
> because you should leave your emacs process running.  On this machine,
> emacs uptime is close to the system uptime.
>
> Keep emacs running, and use emacsclient.  So the boot time is amortized.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> Until real software engineering is developed, the next best practice
> is to develop with a dynamic system that has extreme late binding in
> all aspects. The first system to really do this in an important way
> is Lisp. -- Alan Kay


That's a good point. I guess my problems are exacerbated at the moment
because I just took on Emacs a few weeks ago, so I'm constantly trying
out new packages and testing that my startup process is still working.

Michael

Re: How to Reduce Emacs Load Time

[Pascal J. Bourguignon]

formido <formido@gmail.com> writes:

> Hello there,
>
> Emacs takes like 10 seconds to load. It's a lot faster if I don't load
> all my packages. What strategies could I use to get my load time down?
> Emacs itself is made up of tons of elisp files and it doesn't take
> forever to load, so I don't see why I should be forced to endure long
> load times just because I add third party packages. If I do, 'require
> package', I'm at the mercy of the package maker's initialization
> process, right?

Ah, also even it emacs took one hour to load, it woudn't matter much,
because you should leave your emacs process running.  On this machine,
emacs uptime is close to the system uptime.

Keep emacs running, and use emacsclient.  So the boot time is amortized.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay

Re: How to Reduce Emacs Load Time

[Ivan Kanis]

formido <formido@gmail.com> wrote:

> Emacs takes like 10 seconds to load. It's a lot faster if I don't load
> all my packages. What strategies could I use to get my load time down?
> Emacs itself is made up of tons of elisp files and it doesn't take
> forever to load, so I don't see why I should be forced to endure long
> load times just because I add third party packages. If I do, 'require
> package', I'm at the mercy of the package maker's initialization
> process, right?

Hi,

I use late binding, I load the package when I start using it. For
example for ido mode:

(defun ivan-ido-file ()
  "Find file, late bind ido."
  (interactive)
  (ivan-ido-late-bind)
  (ido-find-file))

(defun ivan-ido-late-bind ()
  (unless ido-mode
    (require 'uniquify)
    (ido-mode 'both)))

I then bind C-x C-f to ivan-ido-file, it will load ido the first time
I need it. This makes my emacs faster to start.

The full code for ido is here
https://kanis.fr/svn/trunk/wk/lisp/emacs.d/ivan-ido.el

I use it for bbdb and gnus as well, it's on the same path.
-- 
Ivan
http://kanis.fr

Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former.
    -- Albert Einstein 

Re: How to Reduce Emacs Load Time

[Nikolaj Schumacher]

pjb@informatimago.com (Pascal J. Bourguignon) wrote:

Another tip:
Use `eval-after-load' a lot.  With that you can load minor modes and
configurations only when a specific major mode has been (auto-)loaded.

I use this to load cedet only when cc-mode is loaded, for example.

> - don't load what you need, yet.  This means, instead of loading or
>   requiring the packages you may need, define autoloading functions.
>   Good packages will do that for you, when you require them, they load
>   only a file which defines autoloading functions, so you spend time
>   loading the package only when you try to run these functions.

I don't think /good/ packages do that, just /huge/ packages.
IHMO the proper thing for packages to do is just add ;;;###autoload
markers, so /you/ can generate the autoloads automatically, if you want
them (using `update-directory-autoloads').

Package managers like ELPA will do that step automatically when the
package is updated.


I actually find it annoying if packages have their own autoloading,
because I need to exclude them specifically.  Pretty much every other
package I can autoload automatically with something like this:  (My
actual code is more complicated, so this is just a prototype...)

(defun update-autoloads ()
  (dolist (file (directory-files package-dir t "[^.]" t))
    (when (file-directory-p file)
      (add-to-list 'loaddef-dirs file)))
  (add-to-list 'loaddef-dirs package-dir)

  (let ((generated-autoload-file autoload-file))
    (apply 'update-directory-autoloads loaddef-dirs)))

and then just
(ignore-errors (load autoload-file))

I only need to define manual autoloads for three packages or so...


regards,
Nikolaj Schumacher

Re: How to Reduce Emacs Load Time

[David]

formido <formido@gmail.com> writes:
> Emacs takes like 10 seconds to load. It's a lot faster if I don't load
> all my packages. What strategies could I use to get my load time down?

First, you should identify what parts of your .emacs take so long. You
can do this e.g. by starting emacs with "emacs -q", set up your
load-path, and then evaluate

(benchmark-run
  (require 'package))

The first number appearing in the echo area will be the time needed to
run that command.

> Emacs itself is made up of tons of elisp files and it doesn't take
> forever to load, so I don't see why I should be forced to endure long
> load times just because I add third party packages.

Many packages from Emacs use autoloads, which delay the loading of the
complete package until one of the interactive functions is used.

> If I do, 'require package', I'm at the mercy of the package maker's
> initialization process, right?

Essentially, yes. But maybe you "require" too much. My emacs startup
time is ~1sec, although I include large third party packages like CEDET
and Gnus. For example, for setting up Gnus, you should only require
'gnus-load in your .emacs, which contains the proper autoloads. This
takes about 0.03 seconds on my machine.

If you want to set options which need to be evaluated after a package is
loaded, you can use eval-after-load.

-David

Re: How to Reduce Emacs Load Time

[Joost Diepenmaat]

formido <formido@gmail.com> writes:

> That's a good point. I guess my problems are exacerbated at the moment
> because I just took on Emacs a few weeks ago, so I'm constantly trying
> out new packages and testing that my startup process is still working.

FWIW: you can test /most/ of the startup configuration by running "M-x
eval-buffer" on your .emacs startup file.

-- 
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Re: How to Reduce Emacs Load Time

[Nikolaj Schumacher]

Ivan Kanis <expire-by-2008-09-05@kanis.fr> wrote:

> I use late binding, I load the package when I start using it. For
> example for ido mode:
>
> (defun ivan-ido-file ()
>   "Find file, late bind ido."
>   (interactive)
>   (ivan-ido-late-bind)
>   (ido-find-file))
>
> (defun ivan-ido-late-bind ()
>   (unless ido-mode
>     (require 'uniquify)
>     (ido-mode 'both)))
>
> I then bind C-x C-f to ivan-ido-file, it will load ido the first time
> I need it. This makes my emacs faster to start.

Emacs already provides a mechanism for that.  I think you can get rid of
most of these custom commands simply with these lines:

(eval-after-load "ido"
  '(progn (unless ido-mode
            (require 'uniquify)
            (ido-mode 'both))))

regards,
Nikolaj Schumacher

Re: How to Reduce Emacs Load Time

[formido]

On Aug 31, 4:26 am, Nikolaj Schumacher <m...@nschum.de> wrote:
> p...@informatimago.com (Pascal J. Bourguignon) wrote:
>
> Another tip:
> Use `eval-after-load' a lot.  With that you can load minor modes and
> configurations only when a specific major mode has been (auto-)loaded.
>
> I use this to load cedet only when cc-mode is loaded, for example.

Haha! I see others have mentioned cedet, too. That's the package
that's causing me the most pain. See, I just followed .emacs setup
instructions, and I went with the whole kit and kaboodle by using the
load-excessive-helper-functions or whatever. My .emacs looks like:

My .emacs has:

(load "lisp/cedet-1.0pre4/common/cedet.elc")
(semantic-load-enable-excessive-code-helpers)

So, when Emacs starts up, the relevant sections of *messages* looks
like this:

Loading lisp/cedet-1.0pre4/common/cedet.elc...
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/common/" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/cogre" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/ede" added to `load-path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/eieio" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/semantic" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/speedbar" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/contrib" added to `load-
path'
Setting up cedet...done
Setting up cogre...done
Setting up ede...
Loading ede...
Loading ede-speedbar...done
Loading ede...done
Setting up ede...done
Setting up eieio...done
Setting up semantic...done
Setting up speedbar...done
Setting up cedet-contrib...done
Loading lisp/cedet-1.0pre4/common/cedet.elc...done
Loading semantic-idle...done
Loading senator...done

WARNING: Probable vocabulary misuse ahead...

I could set cedet to load when a feature I know about is activated,
like cc-mode, but I'm worried that with all that going on above, all
sorts of features and hooks are being set up that I'll then never find
out about. I would have thought that they'd just set up hooks to
autoload functions as necessary. Is all the above necessary just for
that?

> > - don't load what you need, yet.  This means, instead of loading or
> >   requiring the packages you may need, define autoloading functions.
> >   Good packages will do that for you, when you require them, they load
> >   only a file which defines autoloading functions, so you spend time
> >   loading the package only when you try to run these functions.
>
> I don't think /good/ packages do that, just /huge/ packages.
> IHMO the proper thing for packages to do is just add ;;;###autoload
> markers, so /you/ can generate the autoloads automatically, if you want
> them (using `update-directory-autoloads').
>
> Package managers like ELPA will do that step automatically when the
> package is updated.
>
> I actually find it annoying if packages have their own autoloading,
> because I need to exclude them specifically.  Pretty much every other
> package I can autoload automatically with something like this:  (My
> actual code is more complicated, so this is just a prototype...)
>
> (defun update-autoloads ()
>   (dolist (file (directory-files package-dir t "[^.]" t))
>     (when (file-directory-p file)
>       (add-to-list 'loaddef-dirs file)))
>   (add-to-list 'loaddef-dirs package-dir)
>
>   (let ((generated-autoload-file autoload-file))
>     (apply 'update-directory-autoloads loaddef-dirs)))
>
> and then just
> (ignore-errors (load autoload-file))

My elisp-foo is still weak: if I understand right, this function only
works if the packages have been tagged with appropriate metadata,
i.e., autoload markers?

> I only need to define manual autoloads for three packages or so...

> regards,
> Nikolaj Schumacher

Michael

Re: How to Reduce Emacs Load Time

[formido]

On Aug 31, 4:39 am, David <de...@arcor.de> wrote:
> First, you should identify what parts of your .emacs take so long. You
> can do this e.g. by starting emacs with "emacs -q", set up your
> load-path, and then evaluate
>
> (benchmark-run
>   (require 'package))

Thanks very much for that. In this case, by inspection I can tell
CEDET is a major culprit.

> Essentially, yes. But maybe you "require" too much. My emacs startup
> time is ~1sec, although I include large third party packages like CEDET
> and Gnus. For example, for setting up Gnus, you should only require
> 'gnus-load in your .emacs, which contains the proper autoloads. This
> takes about 0.03 seconds on my machine.

Mind telling me how you load CEDET? I just used instruction they gave--
you can see above what my *messages* looks like at init.

> -David

Re: How to Reduce Emacs Load Time

[formido]

On Aug 31, 4:26 am, Nikolaj Schumacher <m...@nschum.de> wrote:

> p...@informatimago.com (Pascal J. Bourguignon) wrote:

> Another tip:
> Use `eval-after-load' a lot.  With that you can load minor modes and
> configurations only when a specific major mode has been (auto-)loaded.

> I use this to load cedet only when cc-mode is loaded, for example.

Haha! I see others have mentioned cedet, too. That's the package
that's causing me the most pain. See, I just followed cedet's .emacs
setup
instructions, and I went with the whole kit and kaboodle by using the
load-excessive-helper-functions or whatever. My .emacs looks like:

(load "lisp/cedet-1.0pre4/common/cedet.elc")
(semantic-load-enable-excessive-code-helpers)

So, when Emacs starts up, the relevant sections of *messages* looks
like this:

Loading lisp/cedet-1.0pre4/common/cedet.elc...
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/common/" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/cogre" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/ede" added to `load-path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/eieio" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/semantic" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/speedbar" added to `load-
path'
"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/contrib" added to `load-
path'
Setting up cedet...done
Setting up cogre...done
Setting up ede...
Loading ede...
Loading ede-speedbar...done
Loading ede...done
Setting up ede...done
Setting up eieio...done
Setting up semantic...done
Setting up speedbar...done
Setting up cedet-contrib...done
Loading lisp/cedet-1.0pre4/common/cedet.elc...done
Loading semantic-idle...done
Loading senator...done

WARNING: Probable vocabulary misuse ahead...

I could set cedet to load when a feature I know about is activated,
like cc-mode, but I'm worried that with everything going on above, all
sorts of features and hooks are being set up that I'll then never find
out about. I would have thought that they'd just set up hooks to
autoload functions as necessary. Is all the above necessary just for
that?

- Hide quoted text -
- Show quoted text -
> > - don't load what you need, yet.  This means, instead of loading or
> >   requiring the packages you may need, define autoloading functions.
> >   Good packages will do that for you, when you require them, they load
> >   only a file which defines autoloading functions, so you spend time
> >   loading the package only when you try to run these functions.

> I don't think /good/ packages do that, just /huge/ packages.
> IHMO the proper thing for packages to do is just add ;;;###autoload
> markers, so /you/ can generate the autoloads automatically, if you want
> them (using `update-directory-autoloads').

> Package managers like ELPA will do that step automatically when the
> package is updated.

> I actually find it annoying if packages have their own autoloading,
> because I need to exclude them specifically.  Pretty much every other
> package I can autoload automatically with something like this:  (My
> actual code is more complicated, so this is just a prototype...)

> (defun update-autoloads ()
>   (dolist (file (directory-files package-dir t "[^.]" t))
>     (when (file-directory-p file)
>       (add-to-list 'loaddef-dirs file)))
>   (add-to-list 'loaddef-dirs package-dir)

>   (let ((generated-autoload-file autoload-file))
>     (apply 'update-directory-autoloads loaddef-dirs)))

> and then just
> (ignore-errors (load autoload-file))

My elisp-foo is still weak: if I understand right, this function only
works if the packages have been tagged with appropriate metadata,
i.e., autoload markers?

> I only need to define manual autoloads for three packages or so...
> regards,
> Nikolaj Schumacher

Michael

Re: How to Reduce Emacs Load Time

[David]

formido <formido@gmail.com> writes:
> Thanks very much for that. In this case, by inspection I can tell
> CEDET is a major culprit.

Strange. I just benchmarked my CEDET init function and it takes about
half a second.

> Mind telling me how you load CEDET? I just used instruction they gave--
> you can see above what my *messages* looks like at init.

Yes, CEDET sets up lots of stuff, but not much is actually loaded, so it
shouldn't take much time. It consists of several packages, which were in
fact separated in earlier releases, but are now bundled to make
installation easier. This is why you see so many messages about
different packages being set up. Don't worry too much about it. :-)

I would strongly advise to use CEDET from CVS. There have been huge
improvements since 1.0pre4, and Eric (Ludlam) is currently preparing a
1.0pre5 release based on the current CVS code.

You can check out the CVS version from sourceforge:

cvs -z3 -d:pserver:anonymous@cedet.cvs.sourceforge.net:/cvsroot/cedet co -P cedet

I usually defer loading CEDET until I load up a source file. You can use
something like this:

(defun my-init-cedet ()
  (interactive)
  (unless (fboundp 'cedet-version)
    (load-file (expand-file-name "~/cedet/common/cedet.el"))
    (semantic-load-enable-gaudy-code-helpers)
    ;; stickyfunc irritates me, so deactivate it
    (global-semantic-stickyfunc-mode -1)
    ))

Then use e.g.

(eval-after-load "cc-mode"
  '(my-init-cedet))

to load CEDET when CC-mode gets loaded. You can add this for several
other modes if you want to. You can also call this init manually.

-David

Re: How to Reduce Emacs Load Time

[Chetan]

Nikolaj Schumacher <me@nschum.de> writes:

> Emacs already provides a mechanism for that.  I think you can get rid of
> most of these custom commands simply with these lines:
>
> (eval-after-load "ido"
>   '(progn (unless ido-mode
>             (require 'uniquify)
>             (ido-mode 'both))))
>
> regards,
> Nikolaj Schumacher

I had seen a lazy load functionality in tiny-tools package. I haven't used it
because I am not really bothered by load time and didn't want to load yet
another library.

http://www.nongnu.org/emacs-tiny-tools/manual/index-body.html#222

I wonder if anybody is using it.

Chetan

Re: How to Reduce Emacs Load Time

[Nikolaj Schumacher]

David <de_bb@arcor.de> wrote:

> formido <formido@gmail.com> writes:
>> Thanks very much for that. In this case, by inspection I can tell
>> CEDET is a major culprit.
>
> Strange. I just benchmarked my CEDET init function and it takes about
> half a second.

Hmmm.  Doesn't semantic support elisp?  In that case the scratch buffer
could be triggering many of the autoloads?


regards,
Nikolaj Schumacher

Re: How to Reduce Emacs Load Time

[David]

>> formido <formido@gmail.com> writes:
>>> Thanks very much for that. In this case, by inspection I can tell
>>> CEDET is a major culprit.

> David <de_bb@arcor.de> wrote:
>> Strange. I just benchmarked my CEDET init function and it takes about
>> half a second.

Nikolaj Schumacher <me@nschum.de> writes:
> Hmmm.  Doesn't semantic support elisp?  In that case the scratch buffer
> could be triggering many of the autoloads?

You are absolutely right! I completely forgot about that. This is why I
also have

(setq initial-major-mode 'text-mode)

in my .emacs.

-David

Re: How to Reduce Emacs Load Time

[Nikolaj Schumacher]

formido <formido@gmail.com> wrote:

> I could set cedet to load when a feature I know about is activated,
> like cc-mode, but I'm worried that with all that going on above, all
> sorts of features and hooks are being set up that I'll then never find
> out about.

Well, CEDET is a huge beast.  It even contains some sort of OO system
for lisp.  I wouldn't think about it too much, there's not much you can
do to speed it up.

I already said, I only load it after cc-mode, but actually, I also start
loading it whenever my Emacs is idle.  I've written a package to do
facilitate this.

http://nschum.de/src/emacs/idle-require/

> My elisp-foo is still weak: if I understand right, this function only
> works if the packages have been tagged with appropriate metadata,
> i.e., autoload markers?

Yes, but many packages come with those markers.  (All bundled packages
use the mechanism as well.)

You can tell if a package supports this by checking if the file contains
the text.
;;;###autoload



regards,
Nikolaj Schumacher

Re: How to Reduce Emacs Load Time

[formido]

On Aug 31, 3:10 pm, Nikolaj Schumacher <m...@nschum.de> wrote:
> David <de...@arcor.de> wrote:
> > formido <form...@gmail.com> writes:
> >> Thanks very much for that. In this case, by inspection I can tell
> >> CEDET is a major culprit.
>
> > Strange. I just benchmarked my CEDET init function and it takes about
> > half a second.
>
> Hmmm.  Doesn't semantic support elisp?  In that case the scratch buffer
> could be triggering many of the autoloads?
>
> regards,
> Nikolaj Schumacher

That's what I was thinking, too, but I'll check it out when I'm at
home later. Or, all the status messages might have mislead me; either
way, I certainly don't intend to slander CEDET. :)

Re: How to Reduce Emacs Load Time

[Ken Goldman]

formido wrote:

> What strategies could I use to get my load time down?

My standard answer is to avoid starting emacs - run it as a server and 
connect clients to it.  When you start it every few months, you won't 
care too much about the startup time.

See gnuclient or emacsclient.

Re: How to Reduce Emacs Load Time

[rustom]

On Sep 2, 11:04 pm, Ken Goldman <kg...@watson.ibm.com> wrote:
> formido wrote:
> > What strategies could I use to get my load time down?
>
> My standard answer is to avoid starting emacs - run it as a server and
> connect clients to it.  When you start it every few months, you won't
> care too much about the startup time.
>
> See gnuclient or emacsclient.

For this to be quite successful one needs ---
1. emacs running as a server -- easily done with (server-start)
2. emacs to be quietly background-able, ie disappear without being
visible on the desktop.  This is not possible because delete-frame
refuses to delete the last frame. In my view delete-frame should
quietly delete the frame if server is running. if not and its the last
frame it should chain to save-buffers-kill-emacs.
3. emacs to be understood as a service by the OS.  This means it must
be compiled and follow the expected convention of service (for
windows) or daemon (for unices).

3 would give maximum convenience but at least 2 is necessary for easy
'service-able' usage (in my humble opinion)

Re: How to Reduce Emacs Load Time

[Rupert Swarbrick]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

rustom <rustompmody@gmail.com> writes:
> For this to be quite successful one needs ---
> 1. emacs running as a server -- easily done with (server-start)
> 2. emacs to be quietly background-able, ie disappear without being
> visible on the desktop.  This is not possible because delete-frame
> refuses to delete the last frame. In my view delete-frame should
> quietly delete the frame if server is running. if not and its the last
> frame it should chain to save-buffers-kill-emacs.
> 3. emacs to be understood as a service by the OS.  This means it must
> be compiled and follow the expected convention of service (for
> windows) or daemon (for unices).
>
> 3 would give maximum convenience but at least 2 is necessary for easy
> 'service-able' usage (in my humble opinion)

I believe one can get emacs to "go away completely" using the Multi-tty
version (which is either a branch or in trunk CVS), but I haven't tried
that yet myself.

What I've been using for quite some time is detailed on the EmacsWiki
[1], and seems to work pretty well. It basically does what you describe
at the end of 2).

Rupert


[1] http://www.emacswiki.org/cgi-bin/wiki/RupertSwarbrick#toc1

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: How to Reduce Emacs Load Time

[rustom]

On Sep 3, 10:06 pm, Rupert Swarbrick <rswarbr...@gmail.com> wrote:
> > For this to be quite successful one needs ---
> > 1. emacs running as a server -- easily done with (server-start)
> > 2. emacs to be quietly background-able, ie disappear without being
> > visible on the desktop.  This is not possible because delete-frame
> > refuses to delete the last frame. In my view delete-frame should
> > quietly delete the frame if server is running. if not and its the last
> > frame it should chain to save-buffers-kill-emacs.
> > 3. emacs to be understood as a service by the OS.  This means it must
> > be compiled and follow the expected convention of service (for
> > windows) or daemon (for unices).
>
> > 3 would give maximum convenience but at least 2 is necessary for easy
> > 'service-able' usage (in my humble opinion)
>
> I believe one can get emacs to "go away completely" using the Multi-tty
> version (which is either a branch or in trunk CVS), but I haven't tried
> that yet myself.
>
> What I've been using for quite some time is detailed on the EmacsWiki
> [1], and seems to work pretty well. It basically does what you describe
> at the end of 2).
>
> Rupert
>
> [1]http://www.emacswiki.org/cgi-bin/wiki/RupertSwarbrick#toc1
>
>  application_pgp-signature_part
> < 1KViewDownload

If you see my post to this list (sub: emacs as a service) and Eli's
response of 29 aug you'll find multi-tty emacs only works and is only
likely to work on linux. Right now I need to work on windows.

Anyhow thanks. This code will still be useful to convert C-x C-c into
a more general purpose 'closer'.

Re: How to Reduce Emacs Load Time

[Eric Ludlam]

>>> formido <formido@gmail.com> seems to think that:
>On Aug 31, 4:26 am, Nikolaj Schumacher <m...@nschum.de> wrote:
>
>Haha! I see others have mentioned cedet, too. That's the package
>that's causing me the most pain. See, I just followed cedet's .emacs
>setup
>instructions, and I went with the whole kit and kaboodle by using the
>load-excessive-helper-functions or whatever. My .emacs looks like:
>
>(load "lisp/cedet-1.0pre4/common/cedet.elc")
>(semantic-load-enable-excessive-code-helpers)
>
>So, when Emacs starts up, the relevant sections of *messages* looks
>like this:
>
>Loading lisp/cedet-1.0pre4/common/cedet.elc...
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/common/" added to `load-
>path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/cogre" added to `load-
>path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/ede" added to `load-path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/eieio" added to `load-
>path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/semantic" added to `load-
>path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/speedbar" added to `load-
>path'
>"/Users/formido/.emacs.d/lisp/cedet-1.0pre4/contrib" added to `load-
>path'
>Setting up cedet...done
>Setting up cogre...done
>Setting up ede...
>Loading ede...
>Loading ede-speedbar...done
>Loading ede...done
>Setting up ede...done
>Setting up eieio...done
>Setting up semantic...done
>Setting up speedbar...done
>Setting up cedet-contrib...done
>Loading lisp/cedet-1.0pre4/common/cedet.elc...done
>Loading semantic-idle...done
>Loading senator...done
>
>WARNING: Probable vocabulary misuse ahead...
>
>I could set cedet to load when a feature I know about is activated,
>like cc-mode, but I'm worried that with everything going on above, all
>sorts of features and hooks are being set up that I'll then never find
>out about. I would have thought that they'd just set up hooks to
>autoload functions as necessary. Is all the above necessary just for
>that?

Hi,

  Those messages from CEDET are just pointing out what it's doing to
your Emacs session.  The "added to `load-path'" line means it checked
some revision numbers, and decided to add something to your load path.
This will help identify if you have multiple conflicting packages
loaded.

  The "Setting up" lines means it is has pulled in the autoloads file
for that package.  That is pretty much the minimum required.

  If you then enabled any of the "global-...-mode" functions, that
forces the package that contains the mode to load, in order to use that
convenience function.

Hope that helps
Eric


-- 
Eric Ludlam                    The MathWorks x 7556  eludlam@mathworks.com
http://www.siege-engine.com                       http://www.mathworks.com