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

[David Kastrup]

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

> 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.

Actually, I try collecting the complexity in fewer places.  I have to
agree that I might be less than successful.  Part of the complexity is
simply that we are dealing with non-trivial problems, part of the
complexity might be my inability to come up with good design.

>>  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).

We still would need to know just _what_ to export.  autoconf has a lot
of internal variables.  Probably not many of them occur in the
expressions we have to deal with, but exporting something like
"prefix" in general seems like asking for trouble.

>> 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.

Ok, and one problem is simply editing: if we had a separate Emacs Lisp
file with the bulk of the code, we would not have quoting problems, we
would have sane indentation, we would have proper comments and so on.

Not to mention that if we designed our interfaces into Emacs code
well, one could actually debug the stuff within Emacs without running
autoconf every time.

At the current point of time, the big inconsistency in installation is
prv-install.el.  It clashes with the rest of the installation
procedure (apart from being XEmacs-only), even though it is supposed
to do pretty much the same job (ok, it generates custom-autoloads as
well, but the way that looks, it could easily be maintained manually),
so it really should be just a special case of the general installation
procedure.

Whether it would be a good idea to shift the general procedure more
towards Elisp is a separate question.

>> 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)

I did not consider the previous state band-aid free enough to make
that desirable.

That is not to say that the current version is much better.  You
actually pinpointed a few problems quite well, even though I was not
really in the right frame of mind to admit them in prerelease panic.

a) the relative specifications have to go.  While we want the results,
we don't want the amount of manual intervention.  I propose that we
"just" use the same mechanism that is now employed for checking
whether something is situated below a standard prefix.  If two
specifications turn out to be in the same general location, the path
is turned into a relative path.

b) in the same course, the MAKE_ABSOLUTE shell abomination is sent the
way of the Dodo.  Instead, that is done using Emacs Lisp.

c) with those changes in place, we can afford to specify the startup
file relative to the lispdir instead of the other way round, so that
one can say something like

--with-package-start=site-start.d/preview-latex.el

which should be the default if it exists.  However, it would be
equally feasible to make the default

--with-package-start=${lispdir}/site-start.d/preview-latex.el

if we don't want to start any of that relative path business.  If the
user specifies a relative path explicitly, considering it relative to
lispdir is probably the best guess, but we need not expose this
default more than necessary.

I think that those are probably the warts we want to have addressed
for AUCTeX-11.80: they still are by far the most ugly thing affecting
the user.

For AUCTeX-11.80, we should probably strive to use the same aclocal.m4
(and thus similar mechanisms), and have configure and make descend
into preview, but other than that, keep stuff mostly separate.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum