Ralf Angeli <[EMAIL PROTECTED]> writes: > * David Kastrup (2005-05-01) writes: > >> Ralf Angeli <[EMAIL PROTECTED]> writes: >> >>> Installation for XEmacs succeeds but after starting XEmacs, the new >>> installation is shadowed by the old one. Here is the start of the >>> output of `list-load-path-shadows': >>> >>> /usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-bar hides >>> /usr/share/xemacs21/site-packages/lisp/auctex/tex-bar >> >> WHAT?!? >> >> Taking a look at the XEmacs in Ubuntu, I see that xemacs-packages is >> _before_ site-packages in the search order. >> >> What idiocy is that? This is completely insane. Whoever at Debian is >> responsible for that ought to be shot. XEmacs in Fedora does not have >> this sick, sick load order. Seems to be a Debian special. > > Yep. It seems that this was done at configuration time. At least > this is what the ./configure string shown in `M-x report-xemacs-bug > RET' suggests.
Did you send the report off to Debian then? >>> auctex.el cannot be located with `locate-library'. >> >> Well, it is called auto_autoloads.el there... > > I see. Interestingly, after accidently executing `make && make > install' for XEmacs again, it seems to pick up the auto_autoloads.el > now. (I don't know if the repeated installation really has > something to do with it or if I just overlooked this the first > time.) Maybe the missing descend for make clean? > At least I now get a popup buffer after starting XEmacs with `xemacs > -q -no-site-file -l auctex-setup.el' telling me this: Uh, auctex-setup.el? > (1) (warning/warning) Autoload error in: > /usr/share/xemacs21/site-packages/lisp/auctex/auto-autoloads: > Symbol's value as variable is void: TeX-fold-keymap Hmpf. What are we doing with that? Doc string formatting or what? If that is the case, maybe one has to do a doc-string-less automode cookie, like I did with the toolbarx-install or so. >>> doing `M-: (unload-feature 'tex-site) RET' will result in a large >>> list printed to the *Messages* buffer. If I then load a LaTeX file, >>> I still get AUCTeX. The same is true with my normal setup which >>> uses (require 'tex-site). As I have `eval-expression-print-length' >>> and `eval-expression-print-level' both set to nil, printing the list >>> to the *Messages* buffer takes _very_ long. >> >> You are not supposed to look at the return value of >> unload-feature... So it is to be used non-interactively. > > I thought that `M-: ...' is non-interactive use, isn't it? You get to see the return value. You don't if you write this in .emacs. >> Ok, so it seemingly does not work. Pity. Would have been nice. >> I'll have to experiment somewhat with that (could be that it is >> easy to fix), Fixed it. The autoloads for the AUCTeX-specific functions don't get removed, but AUCTeX gets yanked from the load-path, so even if you call them explicitly, nothing happens. >> but then the "canonical" way to "unload" will be >> >> (TeX-modes-set 'TeX-modes nil) >> >> if you are allergic to customize, and >> >> M-x customize-variable RET TeX-modes RET >> >> if you can survive it. It will not be a true unload, but it will >> keep AUCTeX off from the modes themselves. > > What gets loaded with this approach? Only tex-site.el, I suppose? Yes, unless you call the AUCTeX-specific functions like TeX-tex-mode. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
