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

[David Kastrup]

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