auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan-Åke Larsson
Subject: Re: [AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever
Date: Fri, 01 Apr 2005 13:57:45 +0200
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; sv-SE; rv:1.7.5) Gecko/20041222

David Kastrup wrote:
The question really is what it would buy us.  "call it from
aclocal.m4" does not exactly like a recipe that would save Windows
users from installing MSYS.  We still need all components, though we'd
pass the threshold between them at fewer times.  So the basic
complaint seems to be "David, we hate the EMACS_LISP macro".

Not really. What I am saying, at least, is that I see an increased
complexity each time we get a bug report.

 One problem is that the autoconf framework relies on a lot of
shell variables that are not necessarily exported.

I suppose we could use a verbatim "export" (the limitations of
"export" in Solaris 2.5, IRIX 6.3, IRIX 5.2, AIX 4.1.5, and
Digital UNIX 4.0 are of no consequence in this case).

At the current point of time, we need the kind of glue that autoconf
gives us into the build systems of distributions.  I think we might at
one time duplicate some functionality into a runtime Emacs-Lisp only
installer/configurator, but it would probably not be feasible to
remove it completely.

I agree. But I see a process where we may end up with a configure script
which does nothing more than reads arguments and ships them to emacs.

As you said in an earlier message, if we start slowly, we'd miss
some shell-quoting bug reports along the way. I'd be very sorry to have
that happen :-)

Anyway, at the moment I am mostly worried about getting 0.9.1
finished, and then we will have to integrate AUCTeX and preview-latex
installation procedures for getting a combined package out.  I don't
think it would make sense to reorganize anything before those changes.

I agree here. (But I'd have preferred to join the two before the changes
of 0.9, but nevermind that now)

And afterwards, it sounds like something that might be better done on
a branch so as to not impede version turnout.

Not a problem either. Shipping new versions with some preceding warning
would achieve the same thing. In theory.

/JÅ




reply via email to

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