auctex-devel
[Top][All Lists]
Advanced

[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 17:42:19 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

>> Yes, that's what has to happen in the long run, anyway, but the
>> current goal is just dealing with the current shortcomings.  0.9
>> already stopped installing into fancyful places mostly.  0.9.1
>> should find the correct places more often, and also make a better
>> decision where multiple possibilities exist.
>
> IMHO 0.9 was a step backward from 0.8.x.

We had several reports that stuff was installed in strange locations
related to idiosyncratic user setups.  This needed to get straightened
out to just keep itself to site installation directories.  Finding out
whether a given path is site installation relative in a shell script,
while keeping track of spaces in file names and slashes and
backslashes and similar on different platforms would have been quite
hopeless.  So I moved this into Elisp.  At least Elisp has a clue
about directory hierarchies and names on different platforms.

> If you had asked me at the time (or given some warning) I would have
> recommended we keep the behaviour of 0.8.x until we had an elisp
> solution. It was not that bad.

Sure.  That's why our Windows configurations broke all over the place,
constantly.  That's why we had to hardcode the XEmacs package-dir
implementation in order to get relative path names.  And I needed
relative paths now also for Emacs instead of just XEmacs: relative
path name expansion for the "images" subdirectory.  That's why we had
to tell people "please copy preview-latex.el someplace sensible when
you are finished, our installation scheme can't deal with that".

I am not saying that I did the best thing possible, but I needed to
get at least the image directory stuff done reasonably.  The new
size-sensitive image code needed to walk through several images, and
it would have been really infeasible to scan through the whole of
load-path each time.

Really, Jan-Åke: I might have messed up a bit in the actual
implementation, but it really was something that was not completely
done out of malice and lunacy.

I checked in some code right now.  The checks should work out now.
aclocal.m4, like it is done now for emacsprefix1 and emacsprefix2, is
probably the wrong place to call the stuff, as it would probably
rather belong into configure.in where it should get used for setting
up the paths, but at least you can take a look at what is intended.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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