[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: Jan-Åke Larsson
Subject: [AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever
Date: Thu, 31 Mar 2005 13:37:58 +0200
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; sv-SE; rv:1.7.5) Gecko/20041222

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.

I did say I didn't write the TeX macro and so shouldn't change it but I
think I have grokked enough of it to allow me to change it somewhat.
I'll have a look. And I'll keep your suggestion in mind.

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?


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.

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
The _vital_ bit is that we allow setting it in the first place.


reply via email to

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