[You'll need to close the new you created by emailing to:
Debian Bug Tracking System <[EMAIL PROTECTED]>
]
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Peter S Galbraith <[EMAIL PROTECTED]> writes:
>
> > Here's what I've decide to do with `emacs-goodies-el' :
> >
> > (if (not (file-exists-p "/usr/share/emacs/site-lisp/emacs-goodies-el"))
> > (message
> > "Package emacs-goodies-el is removed but not purged. Setup not done.")
> > (debian-pkg-add-load-path-item
> > (concat
> > "/usr/share/" (symbol-name flavor) "/site-lisp/emacs-goodies-el"))
> > (require 'emacs-goodies-el))
> >
> > I have moved the bulk of setups in a separate file `emacs-goodies-el.el'
> > that is not under /etc, but that's only because it contains a _lot_ of
> > code.
>
> Note that this will make emacs startup even slower; stat:ing O(k*n)
> files instead of O(n) (where n is number of debian emacs packages you
> have installed, and k depends on the number of additional
> file-exists-p invoked). Compare the startup time of Emacs and XEmacs
> when /usr/share is a network file system to see that this leads to a
> noticeable slowdown. IMHO it would be better to simply treat the
> /etc/emacs.d/ files as non-configuration files and remove them when
> the package is removed, thus making it possible to make them contain
> unconditional autoloads. Even the current O(n) slowdown is so big I
> rarely use the debian built emacs.
>
> Just my $.2.
Unfortunately, that's against Debian policy.
What we need is an alternate directory that is _not_ under /etc
where we could also put Emacs startup files.
That would be the subject of a bew bug report. :-)
Peter
