Re: List of major modes?

Re: List of major modes?

[rgb]

>  From looking at the elisp level code, there is very little
> programmatic distinction between minor and major modes

(kill-all-local-variables)

Should be part of major modes but not minor ones.
Derived modes won't contain a kill-all statement.

Speed up Emacs startup

[Sébastien Vauban]

Hi,

Just a quick question which does not seem so obvious to be
answered: is there an easy way to speed up Emacs launch without
sacrificing the readability and shortness of the .emacs file?

I mean: I don't like the autoload statements where you need tens
of lines instead of one require function call. Is it possible to
write a modified "require" that would provide the same kind of
effect (ie, load files only when they are truly needed OR when
the system is idle)?

Thank you very much,
  Sébastien.

-- 
Sébastien Vauban

Re: Speed up Emacs startup

[Anselm Helbig]

> Just a quick question which does not seem so obvious to be
> answered: is there an easy way to speed up Emacs launch without
> sacrificing the readability and shortness of the .emacs file?
> 
> I mean: I don't like the autoload statements where you need tens
> of lines instead of one require function call. Is it possible to
> write a modified "require" that would provide the same kind of
> effect (ie, load files only when they are truly needed OR when
> the system is idle)?

you can generate the autoloads automatically and put them in your
private loaddefs.el. elisp files have `magic comments' in their code
for this. unfortunately, there only is a mechanism to generate
autoloads for the emacs source tree (speaking of gnu emacs 21 here,
somebody correct/update me if i'm wrong), but you can adapt it for
your private elisp dir. it did something like this (untested, my real
solution was uglier):

(let ((source-directory my-lisp-dir))
  (update-autoloads-from-directories my-lisp-dir))

this way you fool update-autoloads-from-directories to think your
private lisp directory is the emacs source tree, and then have it
generate autoloads for that. a loaddefs.el is generated in your lisp
dir, in the subdirectory `lisp', which you should have created
before. 

(if you don't set/shadow `source-directory' then you probably won't be
able to write loaddefs.el, or your emacs' loaddefs.el will be
overwritten.)

the only line you have to add to your .emacs is something like

	(load (concat my-lisp-dir) "lisp/loaddefs.el")

i hope this solution is elegant enough for you. 8-)

regards, 

anselm

Re: Speed up Emacs startup

[Sébastien Vauban]

Hi Anselm,

> > Is there an easy way to speed up Emacs launch without
> > sacrificing the readability and shortness of the .emacs
> > file?
> >
> > I mean: I don't like the autoload statements where you need
> > tens of lines instead of one require function call. Is it
> > possible to write a modified "require" that would provide
> > the same kind of effect (ie, load files only when they are
> > truly needed OR when the system is idle)?
>
> you can generate the autoloads automatically and put them in
> your private loaddefs.el. [...] The only line you have to add
> to your .emacs is something like
>
>    (load (concat my-lisp-dir) "lisp/loaddefs.el")
>
> i hope this solution is elegant enough for you. 8-)

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?

Best regards,
  Sébastien

-- 
Sébastien Vauban

Re: Speed up Emacs startup

[Anselm Helbig]

hi sebastien, 

At Tue, 22 Nov 2005 13:56:28 +0100,
Sébastien Vauban <ewgeocaufsfb@spammotel.com> wrote:
> 
> 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. i
use gnu emacs 21 under debian linux, and have quite some elisp debian
packages installed. i don't have to worry about autoloading for these
at all, it's done with a file in a special startup directory (debian
has modified emacs to use it). 

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.

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. 

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 other words: maybe just having a `require'-line in your .emacs is
not the best way to tell what packages you use. you should keep track
of that explicitly somewhere, maybe in a comment block at the start of
your .emacs, or at the start of a corresponding configuration section.

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-)

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

kind regards, 

anselm

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

Re: Speed up Emacs startup

[Anselm Helbig]

hi again, sebastien, 

> 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.
> 
> [...]
> 
> 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.

you could as well code an advice for require and/or load. but maybe
that's just a matter of taste. i prefer to use as much of the
`built-in' infrastructure as possible. 

another drawback of you approach: if someone copies snippets of your
.emacs, they won't work unless he or she copies your
`try-require'-defun as well. this cannot happen if you'd use
`require', and you can nevertheless have additional functionality with
`defadvice'. 

but all this depends on your needs, like, how many different
installations you have to use, and how you share your .emacs with
others.

> > 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.

you pay with your longer startup time for that. and regarding your
`wish for completeness': many of emacs' functions are autoloaded, all
the programming modes, for example. but you don't you feel incomplete
when you open the first c-file in a session, do you? 8-)

> > 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...

hum. thinking about it, there is another way, apart from autoloads, to
make emacs start faster: you can dump your own executable with all
your packages already loaded. read more about it here:

	(info "(Elisp)GNU Emacs Internals")

there's also a page on emacswiki.org about this, with a more detailed
explanation on how to actually use this. i tried it, and ran into some
problems, my dumped emacs behaved sort of weird - maybe you're more
determined and can make it work for you. 8-)

anyway, there are many ways to achieve things in emacs, so everyone
can take what they like best and customize the hell out of this
beast. 

but, hey, the way _i_ use emacs is of course the best. and my taste in music
is superior as well. 8;->>

kind regards and (all-hail-emacs), 

anselm

Re: Speed up Emacs startup

[Ismael Valladolid Torres]

[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]

Sébastien Vauban wrote:

> 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.

Why not just using locate-library to require the package only if it's
installed and locatable? There are plenty of sentences like this in my
.emacs:

(when (locate-library "muttrc")
  (require 'muttrc))

Cordially, Ismael
-- 
Dropping science like when Galileo dropped his orange


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: Speed up Emacs startup

[Jason Rumney]

Ismael Valladolid Torres <ismaeval@free.fr> writes:

> Sébastien Vauban wrote:
>
>> 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.
>
> Why not just using locate-library to require the package only if it's
> installed and locatable? There are plenty of sentences like this in my
> .emacs:
>
> (when (locate-library "muttrc")
>   (require 'muttrc))

Why not just use the optional third argument to require?

(require 'muttrc nil t)

Re: Speed up Emacs startup

[Stefan Monnier]

> Why not just using locate-library to require the package only if it's
> installed and locatable? There are plenty of sentences like this in my
> .emacs:

> (when (locate-library "muttrc")
>   (require 'muttrc))

The try-require does the same, just more efficiently: when the library is
absent, locate-library and try-require both just go through all the dirs in
load-path and then give up (i.e. no difference).  But if the lib is present,
then in your case locate-library will go through load-path once and require
will go through it again a second time (and it may still signal an error so
you still want to protect yourself against failure).


        Stefan

Re: Speed up Emacs startup

[Lennart Borgman]

Sébastien Vauban wrote:

>Hi,
>
>Just a quick question which does not seem so obvious to be
>answered: is there an easy way to speed up Emacs launch without
>sacrificing the readability and shortness of the .emacs file?
>
>I mean: I don't like the autoload statements where you need tens
>of lines instead of one require function call. Is it possible to
>write a modified "require" that would provide the same kind of
>effect (ie, load files only when they are truly needed OR when
>the system is idle)?
>  
>
Are you running Emacs as an "edit server"? If you use gnuserv/gnuclient 
you only have to start Emacs once (but maybe that is not your problem).

Re: Speed up Emacs startup

[Stefan Monnier]

> Just a quick question which does not seem so obvious to be
> answered: is there an easy way to speed up Emacs launch without
> sacrificing the readability and shortness of the .emacs file?

Try install.el.  Beware, it's not polished.


        Stefan