auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Re: Running out of time...


From: Ralf Angeli
Subject: Re: [AUCTeX-devel] Re: Running out of time...
Date: Mon, 02 May 2005 09:18:35 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

* David Kastrup (2005-05-01) writes:

> Ralf Angeli <address@hidden> 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.

>> 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.)  At least
I now get a popup buffer after starting XEmacs with `xemacs -q
-no-site-file -l auctex-setup.el' telling me this:

(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

>> 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?

> 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), 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?

-- 
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]