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

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * 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.

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