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

[Jan-Åke Larsson]

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?

Again?

> > 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
   --with-packagelispdir='${lispdir}/foo/bar'
The _vital_ bit is that we allow setting it in the first place.

/JÅ