Re: Re: preview-latex 0.9 released...

Jan-Ake Larsson <[email protected]> writes:

> David Kastrup wrote:
>> > Agreed. It was based on a "this seems to work" test. libdir was
>> > there for xemacs sake, and is no more. Does this work on xemacs?
>>=20
>> Did here.  Where do you think the XEmacs RPM was coming from?  But
>> of course I have had not much feedback to rely on, and given the
>> resonance on the group in the last month or so, it would have been
>> very optimistic to hope that this would improve without a bad
>> release.
>>=20
>> I did not hope it to be bad, but I now we are at least getting
>> feedback.
>
> Lunch hour. I hope I get some food too.=20
>
> If $prefix is NONE, it is set to $ac_default_prefix now. May I suggest
>
> AC_DEFUN(EMACS_SET_PREFIX,[
>   if test "${prefix}" =3D NONE -o -z "${prefix}"; then
>     AC_MSG_CHECKING([for prefix of $EMACS_FLAVOR])
>     EMACS_LISP(prefix,[(expand-file-name \"..\" invocation-directory)])
>     AC_MSG_RESULT([$prefix])
>   fi
> ])

It's not really an idea I'm overly comfortable with.  Because it means
that using an Emacs in a nonstandard location will stop making an
installation work on an otherwise standard system.

In particular, the TeX directories are also looked for
prefix-relative.

>> > What worries me is that the current code seems to pick out the first
>> > entry in load-path that matches "site-lisp" or "site-packages". I'm
>> > not sure this is very robust either.
>>=20
>> Sure, so we have to sort our choice better.  Sorry for that.
>
> Well, you do check that it is the last in the path string.

I do?  Since when?

> What worries me is users who have modified load-path.... but then
> again you enforce that $prefix or $datadir is in the start of the
> path string.  Perhaps that is enough.

Well, we could introduce a few heuristics.  Like preferring the
shortest path (either in characters or in total slashes) at each level
we are looking at things.

Anyway, a warning to all people: I have decided that the current
situation appears to hold up people fixing what I have started.  The
active participation of preview-latex developers on the CVS is mostly
restricted to myself at the moment, of course not counting the dvipng
involvement.

I want our AUCTeX developers to be able to take a pick at what is
intended to become the procedure for AUCTeX, anyway.

So I am packaging the nightly snapshot of preview-latex this night and
am sending it to the Savannah hackers.  I don't know how long it will
take them to place it in the archive: I have not preannounced
anything.  I will tell them to place everything for now, and that
dvipng is possibly intended as a separate non-GNU project on
Savannah.  If doing otherwise would cause work, I don't mind if the
anonymous and web access reflect dvipng until this has been decided
and sorted out and dvipng either moved or removed on Savannah.

_If_ Jan-=C5ke decides to switch (he has been pondering it at one time),
it will probably make things a tiny bit easier.  If he doesn't,
removing dvipng again will not make much work.  I'll ask to get
everything placed into a subdirectory "preview" for starters.

Then we can consolidate installation procedures for both projects in
one go.  preview-latex developers that want to continue can ask for an
account at savannah.gnu.org (reasonably easy to get via the web
interface) if they have not done so before.  I'll also start reminding
people about the copyright assignments soon that we need, in case they
have not done so before.

--=20
David Kastrup, Kriemhildstr. 15, 44793 Bochum


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click