For details see
http://bugzilla.novell.com/show_bug.cgi?id=130379
(please ignore the comments talking about "apel", this
is something else, not related to the "edmacro" problem).
I made a patch to avoid that "edmacro" is always
autoloaded (comment #12 in the bug report mentioned above, also
attached to this mail).
This patch *might* have side effects when using xwem though,
I'm not sure.
I tried to explain the problem in comments #14 and #15 of the above
bug report as far as I understand it. Reproduced here
for your convenience:
/usr/share/xemacs/xemacs-packages/lisp/xwem/xwem-clgen.el contains:
;;;###autoload
(defvar xwem-clgen-map
(let ((map (make-sparse-keymap)))
(define-key map (kbd "H-c H-o") 'xwem-clgen-toggle-other-on-split)
map)
"Local keymap for generic clients.")
Therefore
(defvar xwem-clgen-map
(let ((map (make-sparse-keymap)))
(define-key map (kbd "H-c H-o") 'xwem-clgen-toggle-other-on-split)
map)
"Local keymap for generic clients.")
will be generated into
/usr/share/xemacs/xemacs-packages/lisp/xwem/auto-autoloads.el
This will be read evaluated when XEmacs starts up and. During evaluating this,
the macro
'kbd from /usr/share/xemacs/21.5.25.20060327/lisp/keymap.el is evaluated:
(defmacro kbd (keys)
"Convert KEYS to the internal Emacs key representation.
KEYS should be a string constant in the format used for
saving keyboard macros (see `insert-kbd-macro')."
(if (or (stringp keys)
(vectorp keys))
;; #### need to move xemacs-base into the core!!!!!!
(declare-fboundp (read-kbd-macro keys))
`(declare-fboundp (read-kbd-macro ,keys))))
This macro contains a call to the function 'read-kbd-macro which is
defined in
/usr/share/xemacs/xemacs-packages/lisp/xemacs-base/edmacro.el
Therefore edmacro.el is loaded if it is not already there. And this
causes the messages about loading "edmacro":
mfabian@shannon:~$ xemacs -nw -q -vanilla -kill
Loading edmacro...
Loading edmacro...done
mfabian@shannon:~$
The patch from comment #12 avoids this problem because it removes this
autoload.
What I still don't understand is the following:
Why does this problem *not* occur if XEmacs is build manually?
When building XEmacs for the SuSE packages, we build it in a clean
chroot environment which contains only the stuff necessary to build
XEmacs. Note that this chroot environment does *not* contain the Sumo
packages! As far as I know the Sumo packages do not need to be
installed while building XEmacs.
This could be the difference between building manually, when the Sumo
packages are possibly installed and building in the chroot with the
SuSE build system where the Sumo packages are *not* installed.
Maybe, if the Sumo packages are installed, some extra stuff is dumped
into the XEmacs binary (or external dump file) which is not dumped if
the Sumo packages are not installed.
--
Mike FABIAN <mfabian(a)suse.de>
http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。