List of major modes?

List of major modes?

[David Reitter]

How would I go about compiling a list of all major modes available in  
the current emacs session?
(Both loaded ones and autoloadable ones.)

My first thought was doing something like

  (apropos-internal ".*-mode$")

which works, but doesn't distinguish between major and minor modes,  
which would be important.

I cannot actually run any of the mode functions (would take way too  
long).

 From looking at the elisp level code, there is very little  
programmatic distinction between minor and major modes, at least  
nothing that could be easily detected.

thanks...

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.

Re: List of major modes?

[Edward O'Connor]

David Reitter wrote:

> How would I go about compiling a list of all major modes available in
> the current emacs session?

>From my .emacs; originally from Kevin Rodgers:

(defun kr-major-mode-p (symbol)
  "Return non-nil if SYMBOL is a major mode.
Used in `interactive' forms to read major mode names from the user."
  (and (fboundp symbol)
       (let ((function-name (symbol-name symbol)))
         (and (string-match "-mode\\'" function-name)
              (not (string-match "\\`turn-\\(on\\|off\\)-"
                                 function-name))))
       (not (assq symbol minor-mode-alist))))

You could use this together with `mapatoms' to find all major modes.


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: List of major modes?

[Kevin Rodgers]

David Reitter wrote:
 > How would I go about compiling a list of all major modes available in
 > the current emacs session?
 > (Both loaded ones and autoloadable ones.)
 >
 > My first thought was doing something like
 >
 >  (apropos-internal ".*-mode$")
 >
 > which works, but doesn't distinguish between major and minor modes,
 > which would be important.
 >
 > I cannot actually run any of the mode functions (would take way too 
long).
 >
 >  From looking at the elisp level code, there is very little
 > programmatic distinction between minor and major modes, at least
 > nothing that could be easily detected.

Here's the best I could come up with:

(apropos-internal "-mode\\'"
                   (lambda (mode)
                     (and (commandp mode)
                          (string-match "\\`Major mode\\>"
                                        (documentation mode)))))

-- 
Kevin Rodgers

Re: List of major modes?

[rgb]

> Here's the best I could come up with:
>
> (apropos-internal "-mode\\'"
>                    (lambda (mode)
>                      (and (commandp mode)
>                           (string-match "\\`Major mode\\>"
>                                         (documentation mode)))))

Slick.
It needed a slight tweek on my machine running CVS Emacs.
(documentation mode) would sometimes return nil and blow up
string-match.  tooltip-mode was one that returned nil.  I don't
understand why though.  It does seem to be documented.... hmm.

(apropos-internal "-mode\\'"
                   (lambda (mode)
                     (and (commandp mode) (message "%s" mode)
                          (string-match "\\`Major mode\\>"
                                        (concat "" (documentation
mode))))))

Re: List of major modes?

[Lennart Borgman]

rgb wrote:

>>Here's the best I could come up with:
>>
>>(apropos-internal "-mode\\'"
>>                   (lambda (mode)
>>                     (and (commandp mode)
>>                          (string-match "\\`Major mode\\>"
>>                                        (documentation mode)))))
>>    
>>
>
>Slick.
>It needed a slight tweek on my machine running CVS Emacs.
>(documentation mode) would sometimes return nil and blow up
>string-match.  tooltip-mode was one that returned nil.  I don't
>understand why though.  It does seem to be documented.... hmm.
>  
>
C-h f tooltip-mode RET gives a default help string. This actually says 
that tooltip-mode is not documented.

Re: List of major modes?

[rgb]

> C-h f tooltip-mode RET gives a default help string. This actually says
> that tooltip-mode is not documented.

I was hoping you were right but C-h f tooltip-mode gives me this:

tooltip-mode is an interactive compiled Lisp function in `tooltip.el'.
It is bound to <menu-bar> <options> <showhide> <showhide-tooltip-mode>.
(tooltip-mode &optional arg)

Not documented.

[back]

Popping into tooltip.el shows this:

(define-minor-mode tooltip-mode
  "Toggle Tooltip display.
With ARG, turn tooltip mode on if and only if ARG is positive."
  :global t
...

The reason for the help string not showing up makes me doubt
the reliability of the results returned by Kevin's routine.

Re: List of major modes?

[David Reitter]

>        (not (assq symbol minor-mode-alist))))

Good idea, but unfortunately minor-mode-alist contains stuff to be  
shown in the mode-line, so we're not excluding minor modes that don't  
display anything in the mode line (mouse-wheel-mode for example).

Searching the documentation string (Kevin's idea) won't be reliable,  
obviously.

Looking for (kill-all-local-variables) in the definition would be  
another possibility, but who guarantees that this will occur in the  
mode function definition directly, and not in some function called  
from there.

The only solution I can see is to patch define-minor-mode - as a last  
resort.

- D

Re: List of major modes?

[Henrik Enberg]

> From: David Reitter <david.reitter@gmail.com>
> Date: Fri, 11 Nov 2005 17:56:14 +0000
> 
> >        (not (assq symbol minor-mode-alist))))
> 
> Good idea, but unfortunately minor-mode-alist contains stuff to be  
> shown in the mode-line, so we're not excluding minor modes that don't  
> display anything in the mode line (mouse-wheel-mode for example).

[...]

> The only solution I can see is to patch define-minor-mode - as a last  
> resort.

Not all minor-modes use define-minor-mode.  One way or another, some
stuff will slip through.

RE: List of major modes?

[Drew Adams]

    > unfortunately minor-mode-alist contains stuff to be
    > shown in the mode-line, so we're not excluding minor modes
    > that don't display anything in the mode line

    > The only solution I can see is to patch define-minor-mode -
    > as a last resort.

    Not all minor-modes use define-minor-mode.  One way or another, some
    stuff will slip through.

I agree - some stuff will slip through. I don't think you'll find a 100%
solution for excluding minor modes. There is too much overlap between the
conventions of defining major and minor modes, and too many ways to define
each.

Recent Emacs versions have `minor-mode-list' (not alist), a list of all
minor mode functions. There is no guarantee that it will be complete,
however. It is fed by `add-minor-mode'.

Re: List of major modes?

[Lennart Borgman]

Drew Adams wrote:

>Recent Emacs versions have `minor-mode-list' (not alist), a list of all
>minor mode functions. There is no guarantee that it will be complete,
>however. It is fed by `add-minor-mode'.
>  
>
Would it not be best to make something similar for major modes? There 
are some requirements for what major modes should do and why not add a 
new requirement? It will not be very difficult to add it and many users 
would surely like it.

Re: List of major modes?

[David Reitter]

On 11 Nov 2005, at 19:12, Lennart Borgman wrote:

> Drew Adams wrote:
>
>> Recent Emacs versions have `minor-mode-list' (not alist), a list  
>> of all
>> minor mode functions. There is no guarantee that it will be complete,
>> however. It is fed by `add-minor-mode'.
>>
> Would it not be best to make something similar for major modes?  
> There are some requirements for what major modes should do and why  
> not add a new requirement? It will not be very difficult to add it  
> and many users would surely like it.

Changing the conventions for major modes wouldn't work that well,  
since that would basically create an incompatibility.

The following dynamic definition seems to "sort of" work.

(defun major-modes ()
  (apropos-internal "-mode\\'"
    (lambda (mode)
      (and (commandp mode)
	  (not (string-match "\\`turn-\\(on\\|off\\)-"
	  		     (symbol-name mode)))
   	  (not (assq mode minor-mode-list))))))


I don't know, however, whether minor-mode-list is complete, i.e.  
whether it contains the not-yet-auto-loaded minor modes. From what I  
see in easy-mmode.el, it doesn't look like it. 

Re: List of major modes?

[Lennart Borgman]

David Reitter wrote:

> The following dynamic definition seems to "sort of" work.
>
> (defun major-modes ()
>  (apropos-internal "-mode\\'"
>    (lambda (mode)
>      (and (commandp mode)
>       (not (string-match "\\`turn-\\(on\\|off\\)-"
>                    (symbol-name mode)))
>         (not (assq mode minor-mode-list))))))
>
>
> I don't know, however, whether minor-mode-list is complete, i.e.  
> whether it contains the not-yet-auto-loaded minor modes. From what I  
> see in easy-mmode.el, it doesn't look like it.


Maybe I should change my mind. It looks good. If you marry this with the 
code in describe-mode you can perhaps populate minor-mode-list first 
with all minor modes. At least it seems so in that code. (Older minor 
modes seems to be in minor-mode-alist.)

Re: List of major modes?

[Kevin Rodgers]

David Reitter wrote:
 > The following dynamic definition seems to "sort of" work.
 >
 > (defun major-modes ()
 >  (apropos-internal "-mode\\'"
 >    (lambda (mode)
 >      (and (commandp mode)
 >       (not (string-match "\\`turn-\\(on\\|off\\)-"
 >                    (symbol-name mode)))
 >         (not (assq mode minor-mode-list))))))
 >
 >
 > I don't know, however, whether minor-mode-list is complete, i.e.
 > whether it contains the not-yet-auto-loaded minor modes. From what I
 > see in easy-mmode.el, it doesn't look like it.

I still think it would be better to include functions that follow the
major mode conventions than to exclude functions that don't follow the
minor mode conventions.  The Emacs Lisp manual has nodes describing both
sets of conventions.

For example:

    * The major mode should usually have its own keymap, which is used
      as the local keymap in all buffers in that mode.  The major mode
      command should call `use-local-map' to install this local map.
      *Note Active Keymaps::, for more information.

      This keymap should be stored permanently in a global variable named
      `MODENAME-mode-map'.  Normally the library that defines the mode
      sets this variable.

So you could check (keymapp (intern-soft (concat mode "-map"))) in the
apropos-internal PREDICATE.

-- 
Kevin Rodgers

Re: List of major modes?

[Lennart Borgman]

Kevin Rodgers wrote:

>
> For example:
>
>    * The major mode should usually have its own keymap, which is used
>      as the local keymap in all buffers in that mode.  The major mode
>      command should call `use-local-map' to install this local map.
>      *Note Active Keymaps::, for more information.
>
>      This keymap should be stored permanently in a global variable named
>      `MODENAME-mode-map'.  Normally the library that defines the mode
>      sets this variable.
>
> So you could check (keymapp (intern-soft (concat mode "-map"))) in the
> apropos-internal PREDICATE.
>
What about autoloading?

Re: List of major modes?

[Stefan Monnier]

>> * The major mode should usually have its own keymap, which is used
>> as the local keymap in all buffers in that mode.  The major mode
>> command should call `use-local-map' to install this local map.
>> *Note Active Keymaps::, for more information.
>> 
>> This keymap should be stored permanently in a global variable named
>> `MODENAME-mode-map'.  Normally the library that defines the mode
>> sets this variable.
>> 
>> So you could check (keymapp (intern-soft (concat mode "-map"))) in the
>> apropos-internal PREDICATE.
>> 
> What about autoloading?

Indeed, it's very difficult to tell the difference between an autoloaded
major mode and some other autoloaded function whose name ends in `-mode'.

If the autoload is complete (i.e. generated by a recent autoload.el), then
it'll include the arg list, in which case we can check whether the arglist
is empty (as the convention says).

This said, I'm still not sure why you'd want a list of major modes.


        Stefan

Re: List of major modes?

[Richard M. Stallman]

It is not correct to assume that every major mode has a keymap named
after it.  However, major mode commands take no arguments, whereas
every minor mode command takes an argument.  There may be one or two
exceptions, major mode commands that take arguments, but it would be
easy to put them on a list of exceptions.

Re: List of major modes?

[Alan Mackenzie]

On Mon, 14 Nov 2005, Kevin Rodgers wrote:

>David Reitter wrote:
> > The following dynamic definition seems to "sort of" work.

> > (defun major-modes ()
> >  (apropos-internal "-mode\\'"
> >    (lambda (mode)
> >      (and (commandp mode)
> >       (not (string-match "\\`turn-\\(on\\|off\\)-"
> >                    (symbol-name mode)))
> >         (not (assq mode minor-mode-list))))))


> > I don't know, however, whether minor-mode-list is complete, i.e.
> > whether it contains the not-yet-auto-loaded minor modes. From what I
> > see in easy-mmode.el, it doesn't look like it.

>I still think it would be better to include functions that follow the
>major mode conventions than to exclude functions that don't follow the
>minor mode conventions.  The Emacs Lisp manual has nodes describing both
>sets of conventions.

It is impossible to create a list of major modes, because a major mode is
simply a lisp function, with nothing definitive to distinguish it from
any other lisp function.

So how about having a property `emacs-mode' on symbols, with valid values
(major minor major-minor nil)?  Getting a list of major modes would then
be trivial.  (OK, for Emacs 23. ;-)

>-- 
>Kevin Rodgers

-- 
Alan Mackenzie (Munich, Germany)

Re: List of major modes?

[Lennart Borgman]

Richard M. Stallman wrote:

>It is not correct to assume that every major mode has a keymap named
>after it.  However, major mode commands take no arguments, whereas
>every minor mode command takes an argument.  There may be one or two
>exceptions, major mode commands that take arguments, but it would be
>easy to put them on a list of exceptions.
>  
>
But is information about arguments available for autoloaded functions 
that has not been loaded yet?

Re: List of major modes?

[Kevin Rodgers]

Alan Mackenzie wrote:
 > On Mon, 14 Nov 2005, Kevin Rodgers wrote:
 > > I still think it would be better to include functions that follow the
 > > major mode conventions than to exclude functions that don't follow the
 > > minor mode conventions.  The Emacs Lisp manual has nodes describing 
both
 > > sets of conventions.
 >
 > It is impossible to create a list of major modes, because a major mode is
 > simply a lisp function, with nothing definitive to distinguish it from
 > any other lisp function.

Yes.  We have been discussing heuristics that could be used in the
absence of a definitive test.

 > So how about having a property `emacs-mode' on symbols, with valid values
 > (major minor major-minor nil)?  Getting a list of major modes would then
 > be trivial.  (OK, for Emacs 23. ;-)

Did you mean (major minor global-minor nil)?

-- 
Kevin Rodgers

Re: List of major modes?

[Stefan Monnier]

> But is information about arguments available for autoloaded functions that
> has not been loaded yet?

Sometimes, yes.  See all the "(fn ...)" at the end of doctrings in
loaddefs.el.


        Stefan

Re: List of major modes?

[Richard M. Stallman]

    So how about having a property `emacs-mode' on symbols, with valid values
    (major minor major-minor nil)?  Getting a list of major modes would then
    be trivial.  (OK, for Emacs 23. ;-)

That is straightforward, but it would be substantial trouble.
Is it worth the trouble?

What benefit would it provide?  What was the reason for asking
for this?

Re: List of major modes?

[Richard M. Stallman]

    But is information about arguments available for autoloaded functions 
    that has not been loaded yet?

No, it isn't.  So my proposal won't work.

Thanks.

Re: List of major modes?

[David Reitter]

On 15 Nov 2005, at 10:22, Alan Mackenzie wrote:

> So how about having a property `emacs-mode' on symbols, with valid  
> values
> (major minor major-minor nil)?  Getting a list of major modes would  
> then
> be trivial.  (OK, for Emacs 23. ;-)

How do you make third-party packages compatible without forcing them  
to update their modes?

Richard Stallman wrote:

> That is straightforward, but it would be substantial trouble.
> Is it worth the trouble?
>
> What benefit would it provide?  What was the reason for asking
> for this?

This thread started a while ago when I was asking for a function that  
would give me a list of major mode. What I wanted to write has a  
"switch-to-major-mode" function which would offer - via a completions  
list - a good overview of what modes are available. I think that  
would benefit new users who would be able to explore Emacs that way.

It was found that there was no clean and reliable way to find all  
installed major modes.

Honestly, I don't think implementing a complex mechanism is worth the  
trouble for Emacs 22 at this point. Existing modes wouldn't be  
compatible anyways. The above "newbie function" is probably not that  
important right now.

What might make sense is to add the above property  as a  
recommendation to the mode conventions, pointing out that this will  
be a requirement for Emacs 23 modes.

Re: List of major modes?

[Richard M. Stallman]

    This thread started a while ago when I was asking for a function that  
    would give me a list of major mode. What I wanted to write has a  
    "switch-to-major-mode" function which would offer - via a completions  
    list - a good overview of what modes are available. I think that  
    would benefit new users who would be able to explore Emacs that way.

It doesn't seem terribly important.  I think that anyone who wants to
explore this way will want to look at the modes' doc strings anyway,
and those will show which ones are major modes.  You can do this just
fine with C-h a mode$, so a new feature would provide little benefit.

    What might make sense is to add the above property  as a  
    recommendation to the mode conventions, pointing out that this will  
    be a requirement for Emacs 23 modes.

That would be a lot of work for a lot of people.  My decision is to do
nothing about this.

Re: List of major modes?

[Lennart Borgman]

Richard M. Stallman wrote:

>It doesn't seem terribly important.  I think that anyone who wants to
>explore this way will want to look at the modes' doc strings anyway,
>and those will show which ones are major modes.  You can do this just
>fine with C-h a mode$, so a new feature would provide little benefit.
>
The functionality to show the doc strings from the *Apropos* buffer is 
very good. Should it not be more visible and easy to use for beginners? 
Would it not be easier for them (and many others too) if the the links 
looked the same way as those in the *info* buffer? I believe it would 
help in a case like that we are discussing here.

BTW I would prefer that the links in the *Help* buffer also looked the same.

Re: List of major modes?

[Juri Linkov]

> The functionality to show the doc strings from the *Apropos* buffer is
> very good. Should it not be more visible and easy to use for beginners?
> Would it not be easier for them (and many others too) if the the link
> looked the same way as those in the *info* buffer? I believe it would
> help in a case like that we are discussing here.
>
> BTW I would prefer that the links in the *Help* buffer also looked the same.

Links highlighted in blue stand out more than underlined argument names.
But using a foreground color for argument names might help avoid this problem.
IMO, the following colors for the Help buffer looks good:

  (set-face-foreground 'button "blue")
  (set-face-attribute 'help-argument-name nil
                      :inherit '(font-lock-constant-face italic))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: List of major modes?

[Richard M. Stallman]

Please let's not discuss changes in faces for apropos now.
This is not a bug fix, and not a new feature, and not terribly
important.

How about instead debugging one of the recent bug reports?

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

[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

[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

[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

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