I previously used cvs update to maintain a copy of the xemacs source, but that is no longer accessible to me. I tried to find a function to feed in to debug-on-entry, and find-file looked promising, but debug-on-entry was not known to xemacs, so something seems to have gone wrong in the build. My environment is unchanged from previous incarnations, except that the .xemacs directory has been initialised, and .emacs has gone, following my startup of the new version.

"Peter B. West" <pbwest(a)netscape.net&gt; writes: > I previously used cvs update to maintain a copy of the xemacs source, > but that is no longer accessible to me. > > I tried to find a function to feed in to debug-on-entry, and find-file > looked promising, but debug-on-entry was not known to xemacs, so > something seems to have gone wrong in the build. My environment is > unchanged from previous incarnations, except that the .xemacs directory > has been initialised, and .emacs has gone, following my startup of the > new version. I guess you are suffering from newer package-path detection code. I think you are running XEmacs in place and probably you have CVS xemacs-packages modules checked out parallel to your XEmacs source tree. For example, there are ~/xemacs and ~/xemacs-packages directories and you're running XEmacs with ~/xemacs/src/xemacs. Then your XEmacs will wrongly pick up ~/xemacs-packages as a package directory. That's why you don't get debug-on-entry. The best solution for now is to rename ~/xemacs-packages to something different. I think package detection code should use better heuristics like checking existence of lisp directory, though.