auctex-devel
[Top][All Lists]
Advanced

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

Re: [AUCTeX-devel] Anybody out there?


From: David Kastrup
Subject: Re: [AUCTeX-devel] Anybody out there?
Date: Mon, 11 Apr 2005 23:54:16 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Jan-Åke Larsson <address@hidden> writes:

> David Kastrup wrote:
>> I've seen some spelling fixes from Jan-Åke.  Seems to be less
>> catastrophical than I anticipated, all in all.  Maybe I'll try it
>> out myself.
>
> I might suggest a less mystifying "none found" as positive result of
> the conflict test. And we might write
>
> Conflicts with previous installations have been detected.  Before
> continuing, please remove that installation or use --with-lispdir
> (Emacs) or --with-packagedir (XEmacs) to overwrite the old
> installation
>
> OK?

Be my guest.

> On my debian can it still wants to install into
> ${datadir}/emacs/21.4/site-lisp (with ${prefix}=/usr/local)
> That version-specific directory is not really wanted.

How comes?  The test is

       EMACS_EXAMINE_INSTALLATION_DIR(lispdir,
         [['${datadir}/emacs' '${libdir}/emacs' "${emacsprefix}/share/emacs" \
           '${datadir}' '${libdir}' "${emacsprefix}"]],
         [[(list \"emacs/site-lisp\" \"emacs/site-packages\"
                 \"site-lisp\" \"site-packages\")]], load-path)

And this clearly favors ${datadir}/emacs/site-lisp over
${datadir}/emacs/21.4/site-lisp.

> Also the Emacs prefix is /usr, and there is a "conflicting" install
> in /usr/share/emacs/21.4/site-lisp/. The xemacs install goes into
> /usr/share/xemacs21/site-packages which is OK (a conflicting install
> is in /usr/share/xemacs21/site-lisp, hmmmm)

Frankly, I have been less than successful in figuring out Debian's
Emacs schemes.

> On the Solaris machine it wants to install into
> /sw/gnu/share/emacs/site-lisp which is OK (conflicts on a
> version-specific directory, argh) and the xemacs install in
> /sw/local/lib/xemacs/site-packages, also OK
>
> I think the new way to handle the previewdatadir is good, I hope you
> implemented the relative stuff too.

It does not matter whether you specify stuff relative to lispdir (not!
preview-startfile) or absolutely: if the lispified paths can be
reached relatively from preview-startfile without leaving ${lispdir},
this is done.

> I have a stub configure.el, but I'll leave this as is for now. I
> have no time...

Frankly, this is getting more unimportant by the minute.  The new
procedure is getting into a state where you can use it for extracting
a finished package that can be dropped into an arbitrary Emacs tree
and will run without _any_ preconfiguration.  It is kind of ironic
that by the time a clean preview-latex XEmacs package becomes
possible, we don't want to provide one anymore: conflicts with the
next all-inclusive AUCTeX would not make this feasible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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