[Top][All Lists]

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

[AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever

From: David Kastrup
Subject: [AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever
Date: Thu, 31 Mar 2005 13:58:24 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

> David Kastrup wrote:
>> Jan-Åke Larsson <address@hidden> writes:
>>>> I think it would be better to create another aclocal.m4 macro
>>>> that does this job in a more general way, something like
>>>> AUCTEX_PATH_PREFIX(prefix1, prefix2, executable) which then sets
>>>> the prefix1 and prefix2 variables to the path-relative stuff in
>>>> the manner I outlined previously.
>>> I have checked in a different proposal, which sets $emacsprefix.
>> Which does nothing for TeX.  The "manner I outlined previously" was
>> to set prefix1 to an explicitly specified --prefix option, and
>> prefix2 to a binary derived prefix (by going up, removing a
>> potentially trailing bin/some-architecture or bin), or, when no
>> explicit prefix was specified, setting prefix1 to the binary-derived
>> prefix, and prefix2 to the system default prefix (like /usr/local/).
> This does not solve the problem with different prefixes for emacs and
> the texmf tree, unless we keep setting and resetting $prefix, which I
> think is not desirable.

Well that is why I proposed AUCTEX_PATH_PREFIX gets two explicit
arguments to tell it just which variables to set.  So that one does
not need to keep setting and resetting $prefix.

>>> I have not implemented the explicit list of locations. The current
>>> code matches ${emacsprefix}/.*/site-lisp which perhaps is good
>>> enough. I have little experience with people modifying the
>>> beginning of load-path, is this common?
> Again?

Well, at least we have found that the Emacs-version specific site-lisp
directory typically appears before the Emacs-version neutral site-lisp
directory (which makes sense).

>>> By the way, is there a reason for checking site-packages in that AC
>>> macro, it is only called for GNU Emacs anyway?
>> Not everybody loves the package system.  For those that want to,
>> --without-packagedir is an option.
> Yes. But then they'll get lispdir=no/lisp which may be funny, but not
> very useful. The lispdir checking will not be done anyway, so they'll
> need to specify --with-lispdir=/foo.

Sure about that?  If this is so, it might be called a bug.

>>> Anyway, I have looked at the other things in aclocal.m4 and there
>>> are a few things I do not like, most notably the relative
>>> directories. IMO it would be better to use the absolute path
>>> ${lispdir}/preview than this relative stuff.
>> Nope.  It is vital that we have relative paths for the sake of
>> package systems and prebundled packages.
> Erm, why is this? It is not *that* much more work to say
>     --with-packagelispdir='${lispdir}/foo/bar'
> The _vital_ bit is that we allow setting it in the first place.

Sigh.  The difference is what happens in auto.el.  Relative paths are
coded completely different from absolute paths there.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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