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: David Kastrup
Subject: Re: [AUCTeX-devel] Re: Running out of time...
Date: Wed, 04 May 2005 18:34:00 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-05-02) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> * David Kastrup (2005-05-01) writes:
>>>
>>>> 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?
>
> I needed some time to look for already filed bug reports on this
> matter and for finding a suitable reference in XEmacs' Lispref manual.
> You can find my additions to a formerly filed report at
> <URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151900>.

I am not sure that finding that old report will actually prove
helpful.  The old report is _three_ years old, so the maintainer might
say "oh, it looks like only very few people are unsatisfied with the
current state of affairs".  On the other hand, Ohura Makoto is also
the Debian maintainer of preview-latex, so perhaps this report will be
more relevant for him than the last one.

>>> 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?
>
> That's the file I mentioned earlier which activates AUCTeX and does
> nothing else.  Next time I'll use `emacs -q -no-site-file -eval
> "(require 'tex-site)"'.

Well, it is ok to use -l something.el as long as something.el is the
startup file generated for that purpose.  I was not sure what
auctex-setup.el was intended to be.

>>> (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.
>
> I don't see how this is related to the doc string.
> auto-autoloads.el contains the whole `define-minor-mode' call which
> chokes on the variable used for the keymap.  I don't know if this is
> a common problem on XEmacs but grepping through the xemacs-packages
> directory on my system I found three spots where including the
> `define-minor-mode' call is inhibited.

I just _hate_ that excuse for an editor.  Seems like they did not
teach update-file-autoloads about define-minor-mode.

> Here is one:
>
> ,----[ diff-mode.el.gz ]
> | ;; XEmacs hack: autoload a dummy autoload instead of a minor mode
> | ;;;###autoload(autoload 'diff-minor-mode "diff-mode" nil t)
> | (define-minor-mode diff-minor-mode
> `----

I can't believe that.  Really.  Maybe they have just given up on
reporting bugs.

Could you make up a problem report for our own case, include an
example of what the generated autoloads in Emacs look like, and ask
them what workaround they would recommend until they get their
[expletive deleted] fixed, under the assumption that we prefer not to
lose the doc string in the autoloads for editors which actually work?

Is this with a current version of XEmacs?  Even if it is already
fixed, asking for a good workaround for the XEmacs versions where it
is not might be an idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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