I assume it's because whoever built Emacs at RedHat didn't specify the
paths properly to match the installation paths, so the file that triggers
this behavior didn't get inserted in the site-lisp directory by the Emacs
build process.
If you want to see how this process works, look at the "startup.el" file
for the defun of "normal-top-level-add-subdirs-to-load-path".
If you just want to fix the problem, create a "subdirs.el" file in the
site-lisp directory with the following two lines of Emacs-lisp code:
------
(if (fboundp 'normal-top-level-add-subdirs-to-load-path)
(normal-top-level-add-subdirs-to-load-path))
-----
pete peterson
GenRad, Inc.
7 Technology Park Drive
Westford, MA 01886-0033
[EMAIL PROTECTED] or [EMAIL PROTECTED]
+1-978-589-7478 (GenRad); +1-978-256-5829 (Home: Chelmsford, MA)
+1-978-589-2088 (Closest FAX); +1-978-589-7007 (Main GenRad FAX)
> From: Matthew Campbell <[EMAIL PROTECTED]>
> Date: Sun, 12 Sep 1999 17:13:59 -0500 (CDT)
> To: [EMAIL PROTECTED]
> Subject: Bug in emacs-20.3-15
>
> According to the NEWS file in Emacs 20.3, the load-path variable in
> Emacs automatically includes most subdirectories under
> /usr/local/share/emacs/site-lisp (and the reasons for excluding a
> directory from this list are included). In Red Hat, /usr/local/share
> doesn't exist by default, and directories under
> /usr/share/emacs/site-lisp are not included by default. And if I
> create /usr/local/share/emacs/site-lisp and make a directory under
> that, that directory isn't included by default in the load-path
> variable either. So if an Emacs Lisp package like VM or Emacs/W3 is
> installed in a subdirectory of /usr/share/emacs/site-lisp, that
> subdirectory must be explicitly added to the load-path variable when
> Emacs starts.
>
> Does anyone know why this is happening?
>
> Thanks,
> Matt Campbell
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
